[WIP] [DependencyInjection] added support for expressions in the service container

[fabpot]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#7352
License	MIT
Doc PR	not yet

This PR introduces a way to inject expression in the definition of a service.

Here is a small usage example:

use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Expression;

class Foo
{
    private $value;

    public function __construct($value)
    {
        $this->value = $value;
    }

    public function getBarValue()
    {
        return $this->value;
    }
}

class Bar
{
    public function getValue()
    {
        return 'bar';
    }
}

$c = new ContainerBuilder();
$c->register('bar', 'Bar');
$c->register('foo', 'Foo')->addArgument(new Expression('bar', 'value'));

echo $c->get('foo')->getBarValue()."\n";

Here is the XML version:

    <services>
        <service id="foo" class="Foo">
            <argument type="expression" id="bar" path="value" />
        </service>
        <service id="bar" class="Bar" />
    </services>

And the YAML version:

services:
    bar:
        class: Bar

    foo:
        class: Foo
        arguments: [@bar::value]

The Expression constructor takes a service id and a property path (as defined by the Symfony PropertyAccess component). Using the Symfony PropertyAccess component gives you a lot of flexibility in the way you get data from your objects.

Expressions are not limited to service arguments, you can use them everywhere (like in a method call, a configurator, ...).

Todo

• update documentation
• update all loaders and dumpers
• add tests

Open questions:

• Do we allow some cusomtization of the property access object (like support for __call?)

[lolautruche]

+1 👍
I like this implementation 😃

[lsmith77]

yeah. i think this goes in the right direction.

[fabpot]

I've implemented the YAML and XML loaders (see the description for examples). For the YAML loader, we have to introduce another convention (@bar::value), not sure which one would be better.

[asm89]

How would this work with a dumped container? (php one)

Other than that, interesting to see work on dynamic parameters in the DIC. I'd really like to put database information in for example $_ENV instead of getting it compiled into cache files.

[fabpot]

@asm89 Quite easy: I've just pushed the PHP dumper to let you see how it would work (some details need to be changed but that works).

[fmeynard]

+1 :)

[fabpot]

One limitation (from PropertyAccess) is that you can't pass arguments to method calls. So you can do $foo->bar(), but you cannot do $foo->bar('baz'). If support would be added to the PropertyAccess component, it would be automatically available in the service container.

Note that supporting something like $foo->bar('value of dic parameter baz') would be much more difficult to implement and would probably need that the service container reimplements its own expression language.

[asm89]

@fabpot Nice, looks easy indeed.
@bschussek Any numbers on the performance of PropertyAccessor? In other places I'm not too worried about using the component, but the dumped container should be super optimized imo.

[fabpot]

@asm89 As this is not a feature that people will use that often, I'm not too concerned about performance.

[webmozart]

Looks good! :)

@asm89 The performance is not optimal yet, because PropertyAccessor is using reflection, which is slow. Static code generation for property paths is planned, but I don't know when I (or anyone else) will be able to do this.

@fabpot For reference, in #7726 I suggested a syntax for using property paths in validator.yml:

properties:
    value:
        - Range:
            min: @path.to.min

This would access the "min" property path at the currently validated object. I'm not sure whether the two proposals are consistent.

I wonder what happens when you add a property path as part of a method call?

    my_service:
        calls:
            - [mySetter, [@service::path]]

I suppose this works? What happens if I want to access a path on the same object? (I know this might be a super rare edge case but still, for consistency, we should support it)

I think you should add support for the following syntax:

    my_service:
        calls:
            - [mySetter, [::some.nested.path]]

This would access the property path on the service itself. The syntax for validator.yml could then be configured consistently:

properties:
    value:
        - Range:
            min: ::path.to.min

[fabpot]

Some answers to @bschussek questions:

• @ in the service container is already used in the YAML format to reference a service;
• You can use an expression anywhere in a service definition (so that works in a method call);
• Calling a path on the same object is supported, just use its service id:

my_service:
        calls:
            - [mySetter, [@my_service::some.nested.path]]

Or we can add a special self word to reference the current service (but I don't like this idea).

[fabpot]

I was not clear enough in my first answer. @path.to.min would not work in the service container as it would mean the path.to.min service.

[webmozart]

That's why I suggested ::path.to.min :)

[fabpot]

... which I don't like ;)

[webmozart]

But it would allow for a consistent (=intuitive) syntax in validator.yml... I don't think our users enjoy if the same functionality has a slightly different syntax in different places of the framework.

[cryptocompress]

wondering about the name. can't see an "expression" in this "concrete path":
https://github.com/fabpot/symfony/blob/4a01b5b1990347642c30972a0b577183524ce2dc/src/Symfony/Component/DependencyInjection/Expression.php#L19

[lsmith77]

does spring have anything similar?

[fabpot]

@lsmith77 Spring has this: http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/expressions.html which allow for more complex expression. I named the new feature Expression in reference to Spring but I'm open to any suggestion.

[cryptocompress]

as of $id; in there, name should be something very specific. e.g.: PropertyAccessExpression

http://static.springsource.org/spring/docs/3.2.x/javadoc-api/org/springframework/expression/Expression.html

[Crell]

I'm a bit unclear of the use case here. Do you have a non-foo/bar example of where it would be used, and what it does?

I think from the examples in this thread the idea is to allow a dependency of a service to be fulfilled not by another service, but by the result of a method call on another service. Am I correct in that, or way off base? (If way off base, correct me and ignore the rest of this comment.)

If so, I don't see how I'd specify arguments to said method. If that were resolved, though, I can think of a number of places where Drupal could make use of this, and in fact I really would like to. Because I could see lots of uses for it, the performance of the dumped container really would be relevant as I could see us using that a lot.

[fabpot]

@Crell you are correct, the idea is to be able to inject the result of a method call on another service. As I said in a previous comment, the path is limited to what is currently supported by the Symfony PropertyAccess component, which does not support arguments to method calls.

Can you give us some examples of usage you envision for Drupal? That would make things more clearer than just foo/bar/baz?

[alimovalisher]

Yeah, good idea. +1

[Crell]

Well, the Drupal use case that comes to mind is our configuration system. (We're not using the Symfony Config component, just the YAML parser.)

We have a config.factory service, which acts as a repository for all configuration. Configuration is stored in configuration objects, which map 1:1 to YAML files. We have a lot of services right now that do something along the lines of the following:

doer.stuff:
  class: Stuff
  arguments: ['@url_generator', '@config_factory']

classs Stuff {
  protected $generator;
  protected $config;

  public function __construct(UrlGenerator $generator, ConfigFactory $config_factory) {
    $this->generator = $generator;
    $this->config = $config_factory->get('stuff.things');
  }
}

Some objects are storing the whole config factory instead, too, and then calling $this->configFactory->get('stuff.things') in some other method.

That makes writing unit tests more complicated since you have 2 levels of object to mock. What I think would be better is something along the lines of (YAML syntax totally made up here):

doer.stuff:
  class: Stuff
  arguments: ['@url_generator', '@config_factory::get(stuff.things)']

classs Stuff {
  protected $generator;
  protected $config;

  public function __construct(UrlGenerator $generator, Config $config) {
    $this->generator = $generator;
    $this->config = $config;
  }
}

That makes the Stuff class easier to unit test, as we need only mock the Config object rather than mocking a ConfigFactory object to return a mocked Config object.

(Hopefully that makes sense.)

[denderello]

👍

[docteurklein]

Isn't this functionality a shortcut to something already doable via service factory ?

services:
    bar:
        class: Bar

    bar_value:
        class: stdClass
        factory_service: bar
        factory_method: getValue
        arguments: [ 'bar' ] # arguments for free! ie: no PropertyAccess uage and its limitations

    foo:
        class: Foo
        arguments: [@bar_value]

Maybe I'm wrong, and nevertheless longer than the property path approach.

[gnutix]

Big +1 on this PR (see #7352). As @Crell stated, it would really add a lot of flexibility (and use cases) if we could improve the PropertyAccess component to support methods calls arguments, otherwise we may still be forced to use a similar approach than @docteurklein example in case we need arguments. Seems like a must have ! @bschussek What do you think would be the amount of work for that to happen? I may be able to get some time to work on it.

Concerning the Validator syntax consistency issue, I agree it would be a lot better to have only one syntax all over the framework. But I can't tell which one seems the best. Is the validator syntax already usable in Symfony ? Would it requires a BC break to change it ?

@docteurklein Yes it is, but the class: stdClass is a "non supported hack". See #7352.

[docteurklein]

Thanks for pointing this issue out @gnutix.
However, this is a hack only if the factory service returns scalars.
If it's about naming in #7352, we could imagine a parameter_factory type of service (which is the exact same implementation as service_factory. Mmh.

Anyway, I agree it would be great for flexibility and simplification of current implementations to bypass this limitation (as @Crell shown above).

[hason]

The most popular framework in the Czech republic (nette/nette) has a much more expressive possibilities http://doc.nette.org/en/configuring#toc-configuration-using-neon-files (very similar to the example by @Crell )

services:
    database:
        class: Nette\Database\Connection(%dsn%, %user%, %password%)
        setup:
            - setCacheStorage(@factory::createStorage(%parameter%) )

[Crell]

So that's a couple of votes yes... @fabpot, is adding parameter support at all feasible? (I don't know the internals of the DIC compiler at all.)

[lsmith77]

btw the topic of expressions in config is related to this discussion willdurand/Hateoas#54 .. then again maybe this is more flexibility than we want to offer.

[sstok]

For the PropertyAccess component to support parameter call I think of something like the Expressions used by the JMSSecurityExtraBundle or just giving it an array of parameter and letting the Reflection find there correct position (as reflection is already used right?).

The Spring version also supports things like comparisons and mathematics, should these be considered as well?
Only thing is how much do you want to support as the more complexity is introduced the harder its gets to use the container when not dumped to PHP code, you're only option would be using eval() then.

Just some thoughts.

[lsmith77]

We have in the past consciously decided to not support everything that Spring can. f.e. we dropped interface injection because that meant we would also have to add a syntax to override the interface injections.

[stof]

This feature would make it possible to use https://github.com/opensky/OpenSkyRuntimeConfigBundle the right way instead of abusing services defined by a factory by putting a scalar into the service (which technically break the interface as the container as get($id) is expected to return an object).
However, to make it work with the current version of the bundle, it would also require passing arguments, like in the Drupal case. I guess it could work with PropertyAccess by implementing ArrayAccess or __get and __set to access the properties, but supporting arguments would make it easier.

@bschussek Do you have an idea of how much work this would represent to add it to the PropertyAccess component ? I don't really see how we could add arguments to it as it can access deep paths (and we would need to put the arguments in any level of this path). Maybe we could add support only for ParameterBag-style getters (i.e. get('foo') to access the value for foo) with a special syntax for it (for instance bag.<foo> ? It would be consistent with the way the property path is build for ArrayAccess. This would solve this for the case of Drupal and OpenSkyRuntimeConfigBundle at least.

[stof]

you need to escape quotes in the path to be safe (as you don't have any validation of the path before dumping). Otherwise, it could create some fatal error in the dumped code. I suggest using var_export to build the dumped string instead of just adding quotes around it

[fabpot]

Closing in favor of #8913. The new PR takes a new approach where features asked in the comments are possible. Feedback welcome.