PR updated. @stof I've not addressed your comment #3753 (comment) yet. I don't really get what you mean

@romainneutron you say "You can change the parent service name if you want to:" in the line from @stof's comment, it should be "inner service name" instead of "parent service name"

@wouterj It has already been fixed ^^

You sentence reads as follow:

By convention, the old foo service is going to be renamed foo1.inner

When reading this, people could think that the conventional id foo1.inner is related to the id foo mentionned in the same sentence just before, while it has nothing to do with it (if the old service was named acme_demo.hello_greater, the conventional name would still be foo1.inner). The convention for the generated inner id (foo1.inner) is based on the id of the decorator service (foo1 here), not of the decorated service (foo here). This is mandatory to allow several decorators on the same service (they need to have different generated inner ids).

I would add a note that most of the time, the decorator service should be declared private, as you will not need to retrieve it as foo1 from the container. The visibility of the decorated foo service (whch is an alias for foo1) will still be the same than the original foo visibility.

If the original service is public, this will not have much impact (the runtime access of aliases has been optimized in Symfony 2.4 already so there won't be any overhead if both foo and foo1 are kept public). but if the original service was private, a public foo1 in the call chain will prevent inlining calls to foo (they will still be rewritten to calls to foo1, but not inlined further).

I don't have any use case in mind where you will want your decorator service to have a public id.

@stof thanks for clarification, I've added a note about what you explained in #3753 (comment)

PR has been updated

PR updated, I've fixed code examples

PR updated