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

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 :)