Closed bdrobert closed 1 year ago
I can't think of a case were I'd want the the implementation protocols to have a different scope than the base class, especially since in those cases the base is usually unique (every implemented protocol gets its own) or shared (everyone shares the same implementation).
Of course, just because I can't think of a case doesn't mean that there isn't one... ;)
But to be honest, since there's a workaround for it I'd probably forgo adding the capability to Resolver. It seems just esoteric enough to not justify the added complexity.
I have encountered a use case where I would like to provide a custom scope to ResolverOptions.implements convenience implementation for protocols OR have it default to
.unique
scope OR use the scope of self.registration.Ex. I am resolving a type that itself resolves a collection of homogenous Protocols where the protocols are registered with implements. When resolving the collection Implements uses the default scope but I would expect it to always use .unique in order to always use the scope of the underlying registration.
My attempt at providing this capability via extension won't work due to access control of registration.resolver:![image](https://github.com/hmlongco/Resolver/assets/275516/10ccf07f-7ae2-4a1d-a33d-100ef1228525)
I'm familiar with alternative registration / resolution approaches and can work around this, but I'd like to leverage the implements syntax.
Any thoughts on an approach for this? I'm happy to submit a PR for this and also thanks for all your hard work on Resolver and I look forward to migrating to Factory when projects permit it.