Skip to content

Controlling the order of service decoration #10634

Closed
@stof

Description

@stof

The new decorates feature of the component is great to allow composition. However, the order in which decorators are applied on a given service depends of the order in which definitions are found (the order in which services are defined probably, but not exactly in case service overwrites are involved).

services:
    foo:
        class: Foo

    bar:
        class: Bar
        arguments: ['@bar.inner']
        decorates: foo
        public: false

    foobar:
        class: Foobar
        arguments: ['@foobar.inner']
        decorates: foo
        public: false

This creates the following code (decorators are marked private so that everythng gets inlined so the code is real):

$this->services['foo'] = new Foobar(new Bar(new Foo)));

In some cases, the order of decorators does not really matters. However, there are cases where the order in which they are applied would be important. The current code does not allow to have the following result code:

$this->services['foo'] = new Bar(new Foobar(new Foo)));

Currently, we have some code in Behat 3.0 which is doing some decoration using tags to identify the services. The logic has some flaws (it copies the definition so a different service is used, but I plan to fix it), however it allows controlling the order in which decorators are applied thanks to a priority.
I think it would be great to support such priority for the decorates feature as well. This could be handled by passing a third argument to Definition::setDecoratedService (and using separate attributes in XML and YAML, with names to be determined). this would allow a future version of Behat to rely on the decorates feature rather than using a workaround (we cannot do it now as we want to keep the support of the 2.3 LTS)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions