-
Notifications
You must be signed in to change notification settings - Fork 5k
ServiceCollectionDescriptorExtensions.Add extension method not bound #36128
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.
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
Comments
It does seem like this extension isn't useful. Since it's somewhat harmless we probably won't get to this in 3.0 but I'll label as Moving the |
@anurse I would like to contribute this, but before begin, Add method in ServiceCollection.cs is returns void, so We cant do method chaining. But Add method in ServiceCollectionDescriptorExtensions returns ServiceCollection so it enable us to further chain the other method. Is this a concern? |
Ah, I see, the original intent of the extension method was possibly to add chaining, but it doesn't work, as we can see. We could overcome this issue with different method names. When chaining comes into play, a typical naming convention is to use the "With" prefix. So, we could name the extension methods this way:
and so on. On the othen hand I don't understand why chaining was not implemented with the For consistency I would also propose the following method names when chaining comes into play:
But I think this should decide someone who has a pretty good overview of the conventions used in .NET Core. |
As part of the migration of components from dotnet/extensions to dotnet/runtime (aspnet/Announcements#411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days. If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help! |
Anybody around who knows the initial intent of the extension method? If it was chaining, then we should not use |
Paging @dotnet/extensions-migration ! This issue has been revived from staleness. Please take a look and route to the appropriate repository. |
Tagging subscribers to this area: @eiriktsarpalis |
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process. This process is part of our issue cleanup automation. |
This issue will now be closed since it had been marked |
The compiler does not bind the extension method
ServiceCollectionDescriptorExtensions.Add(this IServiceCollection collection, ServiceDescriptor descriptor)
when the method is called on an instance of typeIServiceCollection
. This is the correct compiler behavior, sinceIServiceCollection
derives fromIList<ServiceDescriptor>
, andIList<>
has an interface definition forAdd
.On the other hand, when calling
Add
on an instance of typeServiceCollection
(the concrete class, not the interface), the compiler binds the extension method. This is due to the fact thatServiceCollection
uses explicit interface method implementation for theAdd
method.This is correct so far, but I wonder what is the point for the extension method?
IServiceCollection
instances.ServiceCollection
instances.ServiceCollection
.Wouldn't it be better to put the null-check into the class implementation?
An alternative is to rename the extension method to something like
AddDescriptor
orAddService
.The text was updated successfully, but these errors were encountered: