PSR-0 != Composer

example.md

A native implementation of PSR-0 using only the autoloader from the PSR-0 example in the spec would expect a folder structure like this:

League\Oauth2\Client\Foo = myapp/somefolder/League/Oauth2/Client/Foo.php
League\Oauth2\Server\Bar = myapp/somefolder/League/Oauth2/Server/Bar.php

If I was making these as packages, I could make them into two packages, which would be installed in different locations, because thats how Composer rolls:

League\Oauth2\Client\Foo = myapp/vendor/league/oauth2/src/League/Oauth2/Client/Foo.php
League\Oauth2\Server\Bar = myapp/vendor/league/oauth2-server/src/League/Oauth2/Server/Bar.php

Phil:

Even the "example" implementation in the spec body itself suffers the same exact problem.

And you missed my point entirely. My original tweet was that "The reference implementation doesn't allow it ;-)". Which indicated that while Composer does allow multiple paths within a namespace, the reference and example implementations do not. Which indicates that the spec does not allow it. Which indicates that the code that you're claiming to be PSR-0 (which is individually), is not actually PSR-0 when used together. Which also indicates that Composer's autoloader itself is not PSR-0 compliant (even though it claims to be)...

And as far as "and that is not how any vaugely right minded person would ever do it.", be very careful what you say or insinuate. Do you claim to know the requirements and usages for all time going forward? I have run into issues like that before. And I can assure you that if you work at it long enough, you will as well.

That attitude of "If you do it this way, it all works" is the fundamental failure here. I'm not advocating that there shouldn't be standards. I'm not even advocating for generic ones. I'm advocating for logically consistent standards (which PSR-0 is not, based on the number of ways we've proven it fails).

And what I'm advocating for is that people like you who are preaching it, understand what and why you are preaching it. I remember back a few years someone very prominent in the PSR/FIG group saying very publicly "PSR-0 is the only autoloading solution we will ever need". And now we have the proposal for the "package loader" because other requirements and workflows are needed. Sure, hind sight is 20-20, but foresight is usually blind. And how arrogant it is of you to make a statement like that is not how any vaugely right minded person would ever do it. Just because there are other ways of thinking and building doesn't imply that they are "not in the right mind".

The fact remains. You claimed PSR-0 allows mapping multiple directories to a single namespace tree quite fine. I pointed out that there are logical inconsistencies that can prevent it from happening, so in general PSR-0 actually does not allow it. Your case (common prefix, different suffixes) is actually a special case, and is the edge-case here. The general case is that it will fatal error. Which is the problem.

Which indicated that while Composer does allow multiple paths within a namespace

No it doesn't. It maps different locations with different namespace prefixes.

the reference and example implementations do not. Which indicates that the spec does not allow it.

SplClassLoader will work in the same way, but you have to do it yourself.

Which indicates that the code that you're claiming to be PSR-0 (which is individually), is not actually PSR-0 when used together.

Sure it is, you can use the example you posted when League\Oauth2\Client is pointed to one Composer package, and League\Oauth2\Server is pointed to another. Thats fine.

That example works if its the SplClassLoader, if you use the actual example in the spec itself then you'd have to merge the folders. It's still PSR-0.

Everything else is irrelevant, based on your misunderstandings of the above.

Except for:

You claimed PSR-0 allows mapping multiple directories to a single namespace tree quite fine.

NOPE. I never did.

I said I could map two different sub-namespaces to two different folders, and it still be perfectly PSR-0 compliant, which is definitely is no matter if I choose to use Composer, SplClassLoader or the example __autoload() function.

Sure, hind sight is 20-20, but foresight is usually blind. And how arrogant it is of you to make a statement like that is not how any vaugely right minded person would ever do it.

A better question is WHY would anyone ever do that?

Install with Composer, and then ignore the Composer autoloader, even ignore the manual class loader, ignore class map and instead choose to manually specify autoloadable points?

It's not arrogant to assume nobody would bother, it's just about as sane as taking a lightbulb out of the socket when you go home instead of turning it off at the switch. Don't go mad on that metafore and say something like "but what if t he switch is broken". I know what you're like :)

Which indicated that while Composer does allow multiple paths within a namespace

No it doesn't. It maps different locations with different namespace prefixes.

Composer allows multiple paths within a namespace. We are using this for Stack to ensure that we can use classes named like Stack\Builder, Stack\Session, and Stack\OAuth for individual middlewares. This is accomplished by setting Stack as the PSR-0 root for each Composer package. Works like a charm.

To see this in action, here is the vendor/composer/autoload_classmap.php generated when you composer install Stack\OAuth:

<?php

// autoload_namespaces.php generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'Symfony\\Component\\Routing\\' => $vendorDir . '/symfony/routing',
    'Symfony\\Component\\HttpKernel\\' => $vendorDir . '/symfony/http-kernel',
    'Symfony\\Component\\HttpFoundation\\' => $vendorDir . '/symfony/http-foundation',
    'Symfony\\Component\\EventDispatcher\\' => $vendorDir . '/symfony/event-dispatcher',
    'Stack' => array(
        $baseDir . '/src',
        $vendorDir . '/stack/builder/src',
        $vendorDir . '/stack/session/src',
        $vendorDir . '/stack/callable-http-kernel/src'
    ),
    'Silex' => $vendorDir . '/silex/silex/src',
    'Psr\\Log\\' => $vendorDir . '/psr/log',
    'Pimple' => $vendorDir . '/pimple/pimple/lib',
    'OAuth' => $vendorDir . '/lusitanian/oauth/src',
);

Cool!

Well in this case, this would be considered a Composer specific feature, which has been added as a super-set to the "sample SplClassLoader implementation" linked in the spec, and not - as Anthony has been insisting - a fault with PSR-0.

And again, thats not what I was even talking about in the first place :)