Remove ClassLoader and generate a map

[composer]

Remove ClassLoader and generate a map

[igorw]

Actually, since PSR-0 is backward-compatible with PEAR, it is supported. You just need to do prefix matching:

$loader = new ClassLoader();
$loader->add('Twig_', __DIR__.'/vendor/twig/lib');
$loader->add('Symfony\\', __DIR__.'/vendor/symfony/src');
$loader->register();

The current loader does support multiple directories per namespace, you just need to set them in the initial add() call. Being able to add others later is a detail, and could easily be added.

[stof]

Another argument to generate a map instead of the autoloader: PHP 5.4 is likely to have an SplClassLoader which will probably be more efficient than PHP implementations so it should be possible to use it.

[naderman]

As per Igor, the class loader in composer is just as powerful as the Symfony2 one, it's just a lot simpler. However I agree that generating just the map in case someone wants to use their own autoloader, but the default mappings, makes sense. So I would simply generate both. One file with the mappings, one file with a default autoloader and one file which adds the map entries to the default auto loader. A project can then decide on its own which file(s) to include.

[Seldaek]

@fabpot: As @igorw said, it is compatible with PEAR. The implementation is more than sufficient imo. The fallbacks and such can easily be done in a second autoloader if that is required, but IMO it'd be just as easy to allow users to configure their namespaces in their composer.json file too. Usually you have only one namespace in the src/ dir anyway.

@stof: You may have noticed that I used add() and register() which AFAIK are the proposed method names for the SplClassLoader (the new version, not the one in the RFC). The point being that we could just use the php one if it's available, once it's merged. Whatever happens with that I'll definitely keep our autoloader in sync. I want it to be a fallback implementation and that's it. Unless the one in core is really not made flexible enough, in which case we can still extend from it or wrap it to speed things up a bit.

Another thing regarding generating a map, I don't really like this too much because I don't think every single project should have an autoloader. It's just commodity stuff that should be given for free. What I would like to do though is have a command that will generate a hardcoded MapClassLoader-like thing on demand. For production this would be nice.