[DI] Decorate the service directly instead of override

[rapisarda]

Description
Add possibility to decorate the service directly instead of override.

Example

override:

services:
    ham_burger:
        class: Burger

    cheese_burger:
        class: Burger

    ham.ham_decorator:
        class: HamDecorator
        decorate: ham_burger

    cheese.cheese_decorator:
        class: CheeseDecorator
        decoration_priority: 2
        decorate: cheese_burger

    ham.cheese_decorator:
        class: CheeseDecorator
        decoration_priority: 1
        decorate: cheese_burger

decorate :

services:
    ham_burger:
        class: Burger
        decorators:
            - HamDecorator

    cheese_burger:
        class: Burger
        decorators:
            - CheeseDecorator
            - HamDecorator

[ro0NL]

At first i liked it :) but we introduce a new (less flexible) concept i believe.

In the first case you are free to modify each decorator as needed. In your proposal we lose this possibility. If we make e.g. decorators: [id, ..., idN] we're back to the current situation more or less by referencing existing services (you could configure them with decorate as well).

TLDR; im not sure how much it increases the complexity of service configuration or what traps we create, given it opens multiple paths.

[stof]

your proposal forbids configuring the decorator services. So it is inferior to the current solution.

[rapisarda]

I don't understand what forbids configuring the decorator services either what is less flexible

services:
    ham_burger:
        class: Burger
        autowire: true
        decorators:
            - HamDecorator

    cheese_burger:
        class: Burger
        decorators:
            - CheeseDecorator
            - HamDecorator
        arguments:
            - 'foo'

  CheeseDecorator:
    arguments: 
      - '@CheeseDecorator.inner'
      - 'cheddar'

  ketchupDecorator:
    decorate: '@ham_burger'

[ro0NL]

it shouldnt be required to use class named service IDs

My worry is CheeseDecorator becomes an implicit decorator (you wouldnt know, only if you see the corresponding cheese_burger service).

What if i start adding decorate: here? Hence we increase complexity IMHO.

[rapisarda]

It's ok, CheeseDecorator definition is ugly

Class named service IDs is mandatory if you want a lot of configuration for the same class and this is probably in case you implement decorator pattern

Thanks for your feedback

[ro0NL]

Class named service IDs is mandatory if you want a lot of configuration for the same class and this is probably in case you implement decorator pattern

not sure i understand that, the same class can be used as a decorator N times.

[stof]

and it also requires the service being decorated to know about its decorators, so it is also less flexible as an extension point.

[stof]

Well, in your proposal, things indeed break if 2 services declare HamDecorator as being their decorator as they would refer to the same service, and so HamDecorator.inner would be one of them.

[rapisarda]

What if decorators: [CheeseDecorator] make a decorator service named like "cheese_burger.CheeseDecorator.decorator" which extend CheeseDecorator abstract service ?
And decorators: {CheeseDecorator: fooDecorator} make a decorator service named "fooDecorator" ?

[stof]

Well, the fact that this would have to create other services would make it a nightmare to configure them if there is any need for an explicit configuration.
And it still does not change the fact that having a service knowing about all its decorator at config time is a much less powerful extension point.

[HellPat]

Is your proposal just syntactical sugar for smth like that (which is already possible)?

services:
    burger:
        class: Burger
        arguments:
            - !service
                class: Ham
                arguments:
                    - !service
                        class: Cheese

[rapisarda]

Exactly. In my case i have something like 30 decorator service with something like 15 decorated services

[nicolas-grekas]

This could work and would be pretty neat to me:

services:
    burger:
        stack:
            - SomeClass: ['@stack.next']
            - AnotherClass:
                calls:
                    - setDecorated: ['@stack.next']
            - TheLastClass # string <=> TheLastClass: []

This would be turned into actual decorators by loaders.