Skip to content

Update autowiring.rst #10625

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Nov 8, 2018
Merged

Update autowiring.rst #10625

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7b85a18
Update autowiring.rst
DonCallisto Oct 31, 2018
6ea7f5e
Update autowiring.rst
DonCallisto Oct 31, 2018
f325679
Update service_container/autowiring.rst
jmsche Nov 7, 2018
88faadd
Update service_container/autowiring.rst
jmsche Nov 7, 2018
42d8fb1
review fix
DonCallisto Nov 8, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions service_container/autowiring.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -341,6 +341,15 @@ Thanks to the ``App\Util\TransformerInterface`` alias, the autowiring subsystem
knows that the ``App\Util\Rot13Transformer`` service should be injected when
dealing with the ``TransformerInterface``.

.. tip::

As long as you have only one concrete implementation of an interface under the same
namespace, alias is not mandatory and autowire will work injecting the concrete
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would reword this a bit:

As long as there is only one class implementing the interface and that class is part of the same namespace configuring the alias is not mandatory and Symfony will automatically create one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I'm gonna change to suggested sentence.

implementation even without alias definition.
Nevertheless it is recommended to provide an alias in order to preserve application
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should drop this sentence. It may be confusing when reading the tip and the error should be clear especially given that we should the alias registration here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would point out somehow that, even if with a single concrete implementation it works, users should declare the alias anyway. Do you think that is superfluous?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure we really need to mention that explicitly. Do you think it adds more clarity (or eases some understanding)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, from one side you're right: we said previously that we need to alias interfaces and in the tip we say that for one single concrete instance, there's no need for alias, so there is a kind of "implicit" context create.
On the other side I would tackle the scenario where someone won't consider future modification such as adding more concrete implementation.
It's not an advice to understand (future) errors rather to suggest that even if it works, to avoid mistakes, it should be better to declare alias.

BTW when writing this, I've noticed that, someone, if we suggest to declare explicitly an alias, user could occur in a situation where code still works but injected type is not "the right one".

Maybe is safer to drop it and keep the "implicit" context as we cannot take into account an "unambiguous" choice/scenario?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW when writing this, I've noticed that, someone, if we suggest to declare explicitly an alias, user could occur in a situation where code still works but injected type is not "the right one".

I am not sure I understand this part. Can you elaborate a bit more what you mean?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes of course.
I mean that if we suggest to create an alias, less experienced users can fall into a situation where, if they add a second or third concrete implementation of that interface (not at the alias creation time but after of course), they could be confused about what is injected and why so I would remove the “Neverthless ...” sentence as you suggested as we cannot determine if “it is better” to provide an alias or not in the single concrete implementation scenario.

Hope to have been more precise this time 🙂

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand now. :) I agree with you. IIRC when there is more than one concrete implementation the DI component will already throw an exception that explains what needs to be changed anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes indeed. I will remove that part. Thanks for the feedback process.

logic when a second concrete implementation kicks in, otherwise compiler compilation
would throw an exception.

Dealing with Multiple Implementations of the Same Type
------------------------------------------------------

Expand Down