[ClassLoader] Added a simplified PSR-0 ClassLoader

The new ClassLoader does not differentiate namespaced classes and
PEAR-like classes like the UniversalClassLoader does as the PEAR
format is a subset of PSR-0.
The new loader registers fallbacks by adding a location for an empty
prefix, as done in Composer. This allows using namespaces map generated
by Composer without any special processing on them.
Changed the test autoloading to use the new autoloader
[ClassLoader] Added an ApcClassLoader

Unlike the ApcUniversalClassLoader, ApcClassLoader uses composition,
meaning it can be used to wrap any object providing a findFile($class)
method. Both the UniversalClassLoader and the new ClassLoader follow
this convention. It can also be used to wrap the Composer autoloader.
fixed CS (missing or misplaced license blocks)
merged branch eriksencosta/cs-fixes (PR #3757)

Commits
-------

2cac50d fixed CS (missing or misplaced license blocks)

Discussion
----------

fixed CS (missing or misplaced license blocks)
[TwigBridge] Added a TwigEngine in the bridge

This TwigEngine implements the interface available in the component.
the TwigBridge in TwigBundle now extends this class and provides only
the additional methods for the FrameworkBundle interface.
moved event dispatcher classes to the EventDispatcher component
merged branch symfony/event_dispatcher_classes_move (PR #3760)

Commits
-------

93848be moved event dispatcher classes to the EventDispatcher component

Discussion
----------

moved event dispatcher classes to the EventDispatcher component

I have moved the two specialized event dispatcher classes from the FrameworkBundle bundle to the EventDispatcher component.

It makes them reusable outside the Symfony full-stack framework as they can be quite useful (people like @drak has a use for them for instance).

It makes the event dispatcher component *optionally* rely on DependencyInjection and HttpKernel for these classes, like what we have in other components.

What do you think?

---------------------------------------------------------------------------

by stof at 2012-04-02T16:02:01Z

you forgot to update the ``suggests`` section of the composer.json file. Otherwise, it is fine

---------------------------------------------------------------------------

by drak at 2012-04-02T16:06:34Z

w00t, thanks @fabpot!

I'm biased of course, but the optional dependency to `DependencyInjection` is a much more logical dependency that the previous one, to `FrameworkBundle`. It immediately shows of the DIC also.

---------------------------------------------------------------------------

by schmittjoh at 2012-04-02T16:06:39Z

+1, the "no dependencies" should really be changed to "minimal dependencies"

---------------------------------------------------------------------------

by henrikbjorn at 2012-04-02T16:09:48Z

@schmittjoh should properly be "minimal optional dependencies" otherwise people will be scared i think :) And reading "minimal dependencies" reminds me when trying to use a zf1 component standalone.

+1

---------------------------------------------------------------------------

by drak at 2012-04-02T16:12:57Z

@schmittjoh Honestly speaking, some of the Sf2 components do already have a few dependencies with each other, but where there are, they all minimal and rather logical anyway.  It's not like some libraries I could mention where one lib required about 10 deps which each rely on a bunch of other things - in the end, you need everything just for one feature :-P

---------------------------------------------------------------------------

by stof at 2012-04-02T16:14:28Z

@drak there was not optional dependency to FrameworkBundle previously as no code of the component was using FrameworkBundle (the dependency was the other way)

---------------------------------------------------------------------------

by drak at 2012-04-02T16:18:31Z

@stof, yeah but I was talking about other components like Security, DependencyInjection, HttpKernel for example which has a mix of optional and required deps.  It's not true to say all Sf2 components are 100% standalone in all cases.
Updated the changelog
[ClassLoader] Added a DebugClassLoader using composition
merged branch stof/twig_engine_move (PR #3761)

Commits
-------

dbab7e1 [TwigBridge] Added a TwigEngine in the bridge

Discussion
----------

[TwigBridge] Added a TwigEngine in the bridge

This TwigEngine implements the interface available in the component.
the TwigBridge in TwigBundle now extends this class and provides only
the additional methods for the FrameworkBundle interface.

This will allow people to support the PhpEngine and Twig in their code more easily when using the component as they don't need to reimplement the class.
I originally thought about when I helped @dragoonis to integrate the Templating component in the PPI framework 2.0 as he talked about adding the support for Twig later too.
Added an exception when passing an invalid object to ApcClassLoader
merged branch stof/autoloader_refactoring (PR #3756)

Commits
-------

f1f1494 Added an exception when passing an invalid object to ApcClassLoader
f5cb167 [ClassLoader] Added a DebugClassLoader using composition
0e54a22 Updated the changelog
eae772e [ClassLoader] Added an ApcClassLoader
4d1333f Changed the test autoloading to use the new autoloader
09850bd [ClassLoader] Added a simplified PSR-0 ClassLoader

Discussion
----------

Autoloader refactoring

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/stof/symfony.png?branch=autoloader_refactoring)](http://travis-ci.org/stof/symfony)

As discussed in #3623, I added a new ClassLoader instead of modifying the UniversalClassLoader, to be able to use the method names without BC concerns. The new class works the same than the composer autoloader regarding the handling of fallbacks, to be able to reuse namespace maps generated by composer.

```php
<?php

// autoload.php
require_once __DIR__.'/vendor/symfony/class-loader/Symfony/Component/ClassLoader/ClassLoader.php';

$loader = new Symfony\Component\ClassLoader\ClassLoader();

$map = require __DIR__.'/vendor/.composer/autoload_namespaces.php';
$loader->addPrefixes($map);

$loader->register();
```

Differences with the composer class loader:

- Composer's ``add`` method is named ``addPrefix`` in the Symfony ClassLoader
- the methods related to the class map are removed as Symfony has a separate laoder for class maps
- the ``addPrefixes`` method is added, accepting a namespace map.

I also added a new ApcClassLoader which uses composition instead of inheriting from a class loader, which makes it far more easier to reuse (we could wrap a Composer autoloader with it for instance).

```php
<?php

$composerLoader = require __DIR__.'/vendor/.composer/autoload.php';

// no need to require the file manually as Composer already registered its autoloader
$cachedLoader = new Symfony\Component\ClassLoader\ApcClassLoader('autoload.my_app', $composerLoader);

$cachedLoader->register();
// unregister the Composer autoloader as we wrapped it in the ApcClassLoader
$composerLoader->unregister();
```

TODO:

- refactor the Debug class loader to use composition too to be able to support different class loaders

---------------------------------------------------------------------------

by fabpot at 2012-04-02T16:31:28Z

Can you update the CHANGELOG and the UPGRADE file accordingly?

---------------------------------------------------------------------------

by stof at 2012-04-02T16:47:43Z

I added a note in the CHANGELOG. There is nothing to add in the UPGRADE file as the change is fully BC (I did not change the UniversalClassLoader at all so it can still be used).

I'm working on the Debug loader right now so please wait a bit before merging

---------------------------------------------------------------------------

by stof at 2012-04-02T17:12:11Z

Here is a new DebugClassLoader using composition too. this way, it is able to support the UniversalClassLoader, the ApcUniversalClassLoader (without dropping the use of APC as done previously), the new ClassLoader, the new ApcClassLoader and even the composer autoloader.
I'm not sure about the use of ``method_exists`` as it could break if an autoloader implements a protected ``findFile`` method (crappy PHP :cry:) but hardcoding the supported classes would be a pain and requiring an interface would make the autoloaders more difficult to use (as the interface would need to be required first) and would drop the support of the composer autoloader.