psr4 psr0_自动装弹机之战：PSR-0与PSR-4

psr4 psr0

If you've gone past the beginner stage in your PHP training, you've heard of PSR-0 – an autoloading standard that defines ways to automatically include PHP classes in your code without having to use statements like require and include.

如果您已经过了PHP培训的初级阶段 ，那么您会听说过PSR-0 (一种自动加载标准)，该标准定义了自动在代码中包含PHP类的方式，而不必使用诸如require和include类的语句。

PSR-0 (PSR-0)

PSR-0 looks at the namespace of a class and discerns its location on the hard drive from that bit of information. For example, the class \Zend\Mail\Message would lead to /path/to/project/lib/vendor/Zend/Mail/Message.php.

PSR-0查看类的名称空间，并从该信息中识别其在硬盘驱动器上的位置。 例如，类\Zend\Mail\Message将导致/path/to/project/lib/vendor/Zend/Mail/Message.php 。

PSR-0 also supports underscores in the class names as an alternative, to make transitioning from 5.2 and earlier easier. Zend_Mail_Message would also lead to /path/to/project/lib/vendor/Zend/Mail/Message.php.

PSR-0还支持在类名中使用下划线作为替代，以简化从5.2或更早版本的转换。 Zend_Mail_Message也将导致/path/to/project/lib/vendor/Zend/Mail/Message.php 。

作曲家 (Composer)

When Composer showed up and took the PHP package management world by storm, things changed. Due to some of its rules, folders often duplicated and became too deep when looking at PSR-0 class installations via Composer. For example, some folder structures ended up like this:

当Composer出现并席卷PHP软件包管理领域时，情况发生了变化。 由于其某些规则，在通过Composer查看PSR-0类安装时，文件夹经常重复并且变得太深。 例如，某些文件夹结构最终如下所示：

vendor/
    vendor_name/
        package_name/
            src/
                Vendor_Name/
                    Package_Name/
                        ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                Vendor_Name/
                    Package_Name/
                        ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest

This is chaotic at best, because:

这充其量是混乱的，因为：

The "src" and "tests" directories have to include vendor and package directory names. This is an artifact of PSR-0 compliance.

“ src”和“ tests”目录必须包含供应商和软件包目录名称。 这是PSR-0遵从性的产物。

Therefore, some highly qualified PHP devs got together and put together a suggestion for a new standard: PSR-4.

因此，一些高素质PHP开发人员聚集在一起，提出了有关新标准PSR-4的建议 。

PSR-4 (PSR-4)

PSR-4 aims to complement and work together with PSR-0 where necessary, not completely replace it. It can, but doesn't have to. The main goal of PSR-4 is to remove the remnants of PSR-0 and the pre-5.3 days completely, and allow for a more concise folder structure. With PSR-4, the above folder tree would look like this:

PSR-4旨在在必要时补充PSR-0并与之合作，而不是完全替代它。 它可以，但不是必须的。 PSR-4的主要目标是完全清除PSR-0和5.3天之前的残留物，并使文件夹结构更简洁。 使用PSR-4，以上文件夹树如下所示：

vendor/
    vendor_name/
        package_name/
            src/
                ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest

Upgrading PSR-0 was not an option

不能升级PSR-0

because PSR-0 does not allow for an intercessory path between any portions of the class name

因为PSR-0不允许在类名称的任何部分之间使用代调路径

This is very important – it means that implementing PSR-4, while allowing for much cleaner packages, would be far more complicated to implement. We call PSR-4 package-oriented autoloading, because it favors package cleanliness before simplicity.

这非常重要–这意味着在实现PSR-4的同时，允许使用更干净的软件包，但实现起来却要复杂得多。 我们将PSR-4称为面向包的自动加载，因为它在简化之前就有利于包的清洁。

选择的方法 (The chosen approach)

The suggested goals are as follows: keep the PSR-0 rule that all packages must contain at least two namespace levels (vendor and package), make sure the vendor-package combo can map to any folder, and allow for an infix of folders between the vendor-package combo and the rest of the fully qualified class name.

建议的目标如下：保持PSR-0规则，即所有程序包必须至少包含两个命名空间级别(供应商和程序包)，确保供应商程序包组合可以映射到任何文件夹，并允许在文件夹之间插入一个前缀供应商软件包组合以及其他完全合格的类名称。

This means we would be able to put our classes anywhere in the package code where it makes sense to us as humans, and still use them smoothly in PHP without writing alternative loading techniques or resorting to manual loading.

这意味着我们可以将我们的类放置在对于人类而言有意义的程序包代码中的任何位置，并且仍然可以在PHP中平稳地使用它们，而无需编写替代的加载技术或求助于手动加载。

Furthermore, the draft explicitly states that a PSR-4 autoloader should never throw exceptions or raise errors simply because multiple autoloaders may be registered, and if one fails to load a class, others should be given the chance to do so – throwing an error and stopping the flow breaks this compatibility. If additional information about the failure is required, one should use a PSR-3 compatible logger or other arbitrary means.

此外，草案明确规定，一个PSR-4自动加载磁带机不应该抛出异常或引发错误，只是因为多个自动加载机可进行登记，如果一个加载失败的一类，其他人应给予这样做的机会-抛出一个错误，停止流将破坏这种兼容性。 如果需要有关故障的其他信息，则应使用与PSR-3兼容的记录仪或其他任意方式。

As illustrated in the example file, using the PSR-4 autoloader to load classes from the following structure:

如示例文件所示 ，使用PSR-4自动加载器从以下结构加载类：

/path/to/packages/foo-bar/
          src/
              Baz.php             # Foo\Bar\Baz
              Qux/
                  Quux.php        # Foo\Bar\Qux\Quux
          tests/
              BazTest.php         # Foo\Bar\BazTest
              Qux/
                  QuuxTest.php    # Foo\Bar\Qux\QuuxTest

would look like this:

看起来像这样：

<?php
    // instantiate the loader
    $loader = new \Example\Psr4AutoloaderClass;

    // register the autoloader
    $loader->register();

    // register the base directories for the namespace    prefix
    $loader->addNamespace('Foo\Bar', '/path/to/packages/foo-bar/src');
    $loader->addNamespace('Foo\Bar', '/path/to/packages/foo-bar/tests');

where calling new \Foo\Bar\Qux\Quux; would attempt to load from the first registered directory, while new \Foo\Bar\Qux\QuuxTest; would attempt to load from the second.

在其中调用new \Foo\Bar\Qux\Quux; 将尝试从第一个注册目录加载，而new \Foo\Bar\Qux\QuuxTest; 会尝试从第二个加载。

This example also illustrates the use of multiple folders per single namespace.

此示例还说明了每个名称空间使用多个文件夹。

结论 (Conclusion)

There is no silver bullet in autoloading. Each approach brings with itself some pros and cons – PSR-4 would allow for simpler folder structures, but would prevent us from knowing the exact path of a class just by looking at the fully qualified name. PSR-0 on the other hand is chaotic on the hard drive, but supports developers who are stuck in the past (the underscore-in-class-name users) and helps us discern the location of a class just by looking at its name.

自动加载没有灵丹妙药。 每种方法都有其优点和缺点– PSR-4允许使用更简单的文件夹结构，但会使我们仅查看完全限定的名称就无法知道类的确切路径。 另一方面，PSR-0在硬盘驱动器上比较混乱，但是它支持过去的开发人员(类名下划线用户)，并帮助我们仅通过查看类名来辨别类的位置。

How do you feel about PSR-4? Let us know in the comments below, or express your opinion in one of the many debates.

您对PSR-4的感觉如何？ 在下面的评论中让我们知道，或者在许多辩论之一中表达您的意见。

Either way – there's no doubt package-oriented autoloading is here to stay. If not formally accepted as a standard, then custom implemented by people who need it. It's up to us to join the discussion and improve the notion enough to reach this formal state.

无论哪种方式–毫无疑问，面向包的自动加载将继续存在。 如果未被正式接受为标准，则由需要它的人自定义实现。 我们应该参加讨论并完善概念以达到这个正式状态。

翻译自: https://www.sitepoint.com/battle-autoloaders-psr-0-vs-psr-4/

psr4 psr0