On Tue, Oct 18, 2016 at 4:11 AM, Xedin Unknown <[email protected]> wrote:
> I'm not sure how this could be useless, or an edge case.
> Like I wrote, the `ParentAwareContainerInterface` would add the concept of
> hierarchy to the standard. This creates the possibility for containers to be
> dependent on other containers for dependency resolution, thus enabling
> lookup delegation. Lookup delegation does not appear to be an edge case,
> since it was talked about quite a bit. It could enable all framework
> components to depend on one single (top-most) container, while at the same
> time hooking in their own standards-compliant containers - completely
> transparent to other modules, and even to other parts of the same module.
> Does this pass as a real use case being used in the wild?
> Or are you saying that lookup delegation may not be something that the
> standard needs? I don't really understand, sorry.
Yes, that's essentially what is being suggested here.
As a maintainer on a project that implemented "parent aware"
containers, I can weigh in on this.
zend-servicemanager provides two types of containers:
- The application-level container (Zend\ServiceManager\ServiceManager)
- Context-specific plugin managers
In the v2 series, the plugin managers implemented an interface we
called `ServiceLocatorAwareInterface`. When a factory was invoked by
requesting a plugin, the factory was passed the plugin manager
instance, from which it could pull the parent container in order to
retrieve application-level dependencies. This would be very similar to
your proposed `ParentAwareContainerInterface` usage, I suspect.
What we observed, and what our users reported, was that 99% of the
time, the only reason they used the provided plugin manager *was to
pull the parent container*, as the plugins inevitably would use
application-level services, not other plugins:
function ($plugins) {
$container = $plugins->getServiceLocator();
return new SomePlugin($container->get('SomeDependency');
}
As such, in v3, we removed the concept entirely, simplifying the
majority use case; factories for plugins are always provided the
parent container:
function ($container) {
return new SomePlugin($container->get('SomeDependency');
}
Of course, this means that if you want to retrieve another peer
plugin, you must first retrieve the plugin manager from the container
you receive; as it's the *minority* use case, we felt it was a
reasonable trade-off. (You can provide an alternate "peering"
container if desired, instead of the application-level container, and
this will instead be passed to factories; despite having implemented
that, however, I have yet to see the feature actually used!)
When it comes to *consumer* usage (usage in a factory becomes an
implementation detail; by consumer, I mean the application and/or
diispatcher that pulls services to execute), I have yet to encounter a
use case where you would (a) need to be aware that a container had
parents, and (b) used that functionality. I can only see a use case
*within factories wired to the container*, and, as noted above,
experience and issue reports we've received indicate it makes more
sense to provide the application-level container, as you can then
traverse where needed if you *do* need to pull a context-specific
service.
If this is not what you mean, I respectfully request that you provide
a detailed use case, demonstrating the usage patterns that would
require such an architecture, and demonstrating how the current
interface will not allow for it.
Thanks!
> On Friday, October 7, 2016 at 6:58:51 PM UTC+2, Xedin Unknown wrote:
>>
>> Hi all,
>>
>> The delegate lookup feature of Container Interop didn't get as much
>> attention as I feel it deserves. Specifically, it is lacking formalization
>> in PHP - an interface. I started this conversation , but was instructed that
>> the mailing list is the better way to go.
>> It seems that many would agree with me in that it would be great to have
>> the standard backed by an interface. There was talk of an interface, but the
>> idea was shot down due to forcing the implementation to declare a setter. I
>> completely agree that forcing a setter is a bad idea.
>> But why not a getter?
>>
>> XedinUnknown/di is an example of an implementation that would achieve
>> lookup delegation while depending on one method of one interface. The rest
>> is implementation details.
>> In short, the container that wishes to delegate must pass its parent (or,
>> in my implementation, the "root" parent), if set, to the service definition
>> callable. If the callable is a composite container, it will forward the call
>> to the first child container that contains the definition. Please find a
>> more expanded description in the repo's Readme.
>>
>> Looking forward to your comments, questions, or suggestions.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/d6f3e768-668f-4eb0-a6c5-2a94ad190082%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Matthew Weier O'Phinney
[email protected]
https://mwop.net/
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAJp_myURd_zO9Hi2iu1TyPrfESpmU2Gbxe64Ukfd1E0UM0WiZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
