PSR-0

PSR-0 PSR-0 is a PHP autoloading standard devised to provide interoperability between Zend Framework, Symfony (software), Composer (software), Doctrine (project), Laravel (web framework), and other PHP libraries. It aimed to formalize directory-to-namespace mapping for projects used in Packagist, easing integration with projects like Drupal, WordPress, Magento, and TYPO3. The proposal was authored and ratified through the PHP-FIG process with input from contributors involved in PEAR, PECL, GitHub, Zend Framework 2, and core contributors associated with PHP 5 and PHP 7.

Overview

PSR-0 defined a convention for translating PHP namespace and class names into file system paths so autoloaders could locate class definitions across projects such as Symfony (software), Zend Framework, Laravel (web framework), CakePHP, CodeIgniter, and Slim (framework). The standard was developed within PHP-FIG alongside other proposals like PSR-1 and PSR-2, intended to improve interoperability among libraries hosted on Packagist and managed via Composer (software). PSR-0 referenced earlier autoloading practices in PEAR and implementations in PECL extensions while aligning with recommendations from influential projects like Doctrine (project) and Symfony (software).

Specifications

PSR-0 specified that a fully-qualified class name such as Example\Namespace\ClassName must map to a file path Example/Namespace/ClassName.php following conventions used by PSR-1 and inspired by PEAR. Namespace separators were converted to directory separators, and underscores in class names were treated as virtual namespace separators similar to legacy code found in Zend Framework and PEAR. The standard required that a top-level namespace or vendor name correspond to a base directory, mirroring practices encouraged by Composer (software) and registry conventions on Packagist. PSR-0 mandated case-sensitive mapping consistent with file systems used by projects deployed on GitHub and GitLab. Implementations were often written leveraging SPL autoloading functions available since PHP 5.3 and utilized in projects such as Drupal, Magento, WordPress, and TYPO3.

Autoloading Example

A typical PSR-0 autoloader registered through SPL might locate classes by iterating base directories for vendor names used by Composer (software) and resolving paths similar to examples provided by Julia Evans-style tutorials and code samples on GitHub. For instance, an autoloader used by Zend Framework or Symfony (software) would translate Vendor\Package\ClassName into Vendor/Package/ClassName.php; underscore-based legacy names such as Vendor_Package_ClassName would map similarly to Vendor/Package/ClassName.php, paralleling conversion rules applied in PEAR. Projects like Doctrine (project) and Laravel (web framework) often included composer.json autoload sections that referenced PSR-0 mappings to enable seamless inclusion in projects hosted on Packagist.

Adoption and Compatibility

PSR-0 saw broad adoption among library authors on Packagist and was supported by Composer (software) from its early releases, enabling interoperability among Symfony (software), Zend Framework, Doctrine (project), Laravel (web framework), Twig (template engine), Monolog, and many packages integrated into Drupal and Magento. Major frameworks and libraries provided backward-compatible adapters to allow legacy PEAR and underscore-prefixed class names to function under PSR-0 conventions. As PHP 5.3 introduced namespaces and later PHP 7 expanded language features, tools like Composer (software) and hosting platforms such as GitHub and GitLab encouraged migration paths from PSR-0 to newer strategies adopted by projects including Symfony (software), Laravel (web framework), and Zend Framework.

Criticism and Deprecation

Over time, PSR-0 drew criticism from maintainers of Symfony (software), Zend Framework, and other projects for ambiguities around underscore handling and for duplicating behavior better handled by stricter conventions. The PHP-FIG eventually recommended PSR-4 as a simplified alternative with clearer rules and fewer legacy compatibility requirements; major tooling such as Composer (software), Packagist, and large repositories on GitHub migrated guidance to PSR-4. Critics cited migration costs for large codebases like Drupal and WordPress integrations and noted tooling complexity for projects supporting both PSR-0 and PSR-4. As a result, PSR-0 was deprecated in favor of PSR-4 in discussions and documentation maintained by PHP-FIG, Composer (software), and other ecosystem stakeholders including Symfony (software), Laravel (web framework), and Zend Framework.

Category:PHP