how would this work to lazy-load extensions ?

Just done some renames.

@stof the goal is to lazy-load the runtime not the extension. An extension is just about declaring which functions/tests/tags/... are available, and they must not depend on any other dependencies. So, the dependencies are part of the runtime, and those can be lazy-loaded when using Symfony or Pimple very easily with some conventions. See the referenced Symfony PR for the implementation of the Form runtime.

I like it :) but it is missing some tests.

@fabpot how does it work for the definition of the callable in Twig_SimpleFilter ? Your Symfony PR would not work on Twig 2, where the callable is typehinted, as it is not callable anymore. And you are already loosing the support of named arguments in 1.x as the callable is not callable anymore.

Please write tests for this feature in Twig, to see whether it works fine

and shouldn't we have a way for extension to tell the compiler whether they use a runtime or no instead of asking loaders to try to provide one ? This would avoid the lookup in all loaders for each extension access, as most extensions won't use it. This could make things much faster.

I know about the callable type hints we have in Twig 2.0, but I'm just going to remove them.

@fabpot this will not solve the fact that we need the callable to access parameters through reflection

To speed things up, I'm going to get the runtime only once per template by doing so when initializing the template and then reference a property, that should be enough.

I've just updated the PR which now is able to deal with named arguments. I still need to add some more tests and perhaps throw an exception when the runtime is different from the extension and theruntime_class is not defined.

@fabpot

we don't have a mechanism to retrieve a service by its class name

I prepared PRsymfony/symfony#18268 for Symfony and created thehttps://github.com/symfonette/class-named-services library.

The only "complexity" is how we are going to make it work with Silex and Symfony as we don't have a mechanism to retrieve a service by its class name :)

Is there anything preventing to use service names (instead of class names)?

All that would be very useful in many frameworks (working just like the way we can register controllers using service names).

Also would it make sense to use container-interop'sContainerInterface? Or if you don't want to use that standard, would PSR-11 be a good candidate for that once/if it passes? I'm trying to see if that could be a good use case for it.

If I understood correctly, you're using the FQCN for lookups against this runtime loader. From the point of view of a Symfony developer, it would feel more natural and convenient if I could use service names instead of FQCN, for several reasons:

• With FQCN, I need a mechanism that resolves the FQCN to a service ID.
• Using service IDs, I can rename/move a class without having to change the loader.
• With service IDs, I can have multiple services using the same class with different configurations.
• Furthermore, service IDs allow me to use aliases to change the implementation depending on configuration/environment.

From Twig's POV, it should not really matter if the string that is used to look up a certain service is a FQCN or an arbitrary service ID or am I missing something?

@derrabus@mnapoli One thing you might have missed is that getting an extension by name has been deprecated very recently (#2148). Extensions are now referenced by their class names only. So, re-adding a name for the runtime looks like going backward at this point.

One "simple" way to get names out of class names would be to provide a map between the class name and the service name or just a default convention on the service name (a prefix + the class name in underscore form or something similar).

@fabpot what we could imagine in Symfony is forcing twig runtimes to be tagged with a specific tag, allowing to build a map of class names to service ids for runtimes.

@stof Exactly, that's what I proposed when I wrote "provide a map between the class name and the service name", convention can be for Silex for instance.

I've started to implement the Symfony counterpart of this PR, see the linked PR, but mostlysymfony/symfony#20092

@derrabus@mnapoli One thing you might have missed is that getting an extension by name has been deprecated very recently (#2148). Extensions are now referenced by their class names only.

Right but if I come back on what you said:

When defining a Twig element, you can now use a class different from the extension: array('ImplementationClass', 'method') or ImplementationClass::method'. Of course, Twig has no idea on how to create an instance of ImplementationClass, so that's the goal of the runtime loader, which most of the time is going to use a dependency injection container to do its work.

So there's a difference between referencing an extension (which is now done by class name), and referencing the callable for an element (functions/filters/tests).

For example a problem we are experiencing in my team is that we have a Twig extension for the whole app that provides everything and anything (lots of filters, functions, etc.). We started with dependency injection in theTwigExtension class but ended up with a clogged constructor and lots of services initialized for nothing. We could split the class in multiple extensions but all the services would still always be loaded.

With your change we could have a singleTwigExtension declaring all the elements, yet have the implementations in separate classes (group in topics that make sense). Each of these classes could be a proper service (use dependency injection fully). With the new "loader" those function/filters/… implementations would only be instantiated when the function/filter/… is actually used, which is more efficient.

So lazy-loading the Twig extension is one thing, but lazy-loading the implementation of the elements (function/filter/…) is another problem and is very interesting. And indeed there's no need for extension names (so#2148 is not conflicting), but there's a need for being able to use services instead of class names inside the callables (new \Twig_SimpleFilter('price', ['app.price_formatter', 'formatPrice']),).

I hope that makes sense.

@mnapoli I think we agree on (almost) everything. The goal of this PR is indeed to lazy-load the runtimes, not the extensions which are now only about how to expand Twig (without the implementation). Using the class name is the best way to not consider how the runtimes are going to be loaded. Using a service name is exactly the same as giving a name to the extension. They already have a unique identifier, the class name.

Anyway, have a look at my PRs on Symfony, everything works quite well as is.