@ro0NL thanks for reporting this issue but I'm afraid I don't understand you. What should we do about this?

• Remove this example because it doesn't work in Symfony 4?
• Add or remove something in the current example? If yes, please show me the new config so I can update it.

Thanks!

Let me do a quick test this weekend, and i'll propose a PR for this page.

If i recall correctly the first example should be:

swift.smpt_transport: # the ID
   class: Swift_SmtpTransport # the Class

Only for namespaced classes using the class as ID value works:

Ns\Some: ~

Using the leading \ in the ID value has no effect, it would still need a class: value.

Using the leading \ in the class value probably works but is inconsistent. I think the issue was it wont work with any check a la $def->getClass() === Some::class (as in PHP we dont get the leading \). But that's a per case issue most likely, in general avoiding the leading \ seems like a good practice, and perhaps should even be normalized somewhere in Symfony.

@javiereguiluz

About the class attribute

# always works
class: MyClass
class: My\Class

# works as of v2.7.32, v2.8.25, v3.2.12, v3.3.5
class: \MyClass
class: \My\Class

So in terms of consistency and providing working example code, even prior to the versions mentioned above, i think we should leave out the leading \ in the class attribute across all docs.

About the service ID

# always works
MyClass: { class: 'MyClass' }
My\Class: ~

# doesnt work / unsupported
MyClass: ~
\MyClass: ~
\My\Class: ~

In this case we should actually provide working example code across all docs. Thus only use variants without leading /, adding the class attribute if necessary or using namespaced classes by default.

Hope this clarifies. Im not aware how many examples are affected actually :)

Thanks for the explanation. As discussed in symfony/symfony#28006, let's not "pollute" the docs with these internal details ... and let's improve the error message shown by Symfony. Thanks!