Now that we have a compilation phase for the DIC, using tags after compilation
is not needed anymore.
Tags were introduced to allow several independant bundles to be able to
interact which each others (remember that each extension knows nothing about
the others).
But during the compilation phase, the container has been merged ans so, all
the information from all bundles are available. This is then the right place
to deal with tags. That way, less work is needed at runtime and the DIC class
in the cache is also much smaller.
For simple cases, it means that you need to process the tag in a compiler pass
and store the information you need in a DIC parameter (have a look at the
TranslatorPass for a very simple example).
So, the PHP dumper does not add tags to the dumped PHP class anymore (it does
not implements TaggedContainerInterface anymore). But tags are still available
on ContainerBuilder instances.
* better separation of concerns
* made TwigBundle independant of the PHP Engine from FrameworkBundle (WIP)
* removed one layer of abstraction in the Templating component (renderers)
* made it easier to create a new Engine for any templating library
* made engines lazy-loaded (PHP engine for instance is not started if you only use Twig)
* reduces memory footprint (if you only use one engine)
* reduces size of compiled classes.php cache file
* made the renderer argument of Storage ctor mandatory
* refactored the Engine class to avoid code duplication
* simplified the check for a template that extends another one but with a different renderer
- inline private services which are references multiple times, but where all references originate from the same definition
- bug fix for non-shared services which were considered shared within the scope in which they were inlined
The current `loadClass()` implementation tries to load a class from the first matching prefix then stops, producing false-negative results. This is especially evident in groups of related libraries, such as Doctrine:
Doctrine
Doctrine\Common
Doctrine\Common\DataFixtures
Doctrine\DBAL
Doctrine\DBAL\Migrations
Each of these libraries is submoduled into a different vendor directory. Depending on what order these libraries are added to a UniversalClassLoader instance, classes may or may not actually be loaded. This fix continues searching registered namespaces and prefixes if the first partial match is negative.
