Hi! This is a lot of text, I'm still not sure I understand the problem we are trying to solve in this thread?
> The `ParentAwareContainerInterface` is a formal way of saying "this container can have a parent". Nothing more, nothing less. Then we are back to discuss "marker-interface" VS "no-interface", which has already been discussed for a long time: if the interface is useless it shouldn't exist. > Thus, this interface is useful to any consumer that needs to be hierarchy-aware. Up to now, there is no concept of hierarchy in the standard, and the use of the interface would be to introduce that concept. Can you point to a real use case that is being used in the wild, and that deserves to be part of a PSR (i.e. that is part of the 80%-90% problem, not just a very isolated use case)? I understand that a few edge case things *might* be possible with it, but the very important question is "do we need it?" Matthieu Le lundi 10 octobre 2016 14:21:55 UTC+2, Xedin Unknown a écrit : > > Just wanted to add something. > > If I understood correctly, David suggested that all hierarchy is flattened > so that all containers have the same parent - the root container - for the > sake of faster lookup. If that is true, than I would like to remind > everyone that in my proposal, the amount of nesting is implementation > detail. If the DI implementation wants to have the same parent for all > containers, *they can do that*. However, I don't see why they must be > required to do that. > My demo implementation would work just the same if there was one level, > without having to change anything. > > Thanks. > > I remain, > Anton. > > On Monday, October 10, 2016 at 12:48:56 PM UTC+2, David Négrier wrote: >> >> >> <https://lh3.googleusercontent.com/-MJQw2yspEUE/V_tt0Bg3xPI/AAAAAAAAB8s/Z6txSatzpM83T_v0AqUvcQXvgitUuzS1ACLcB/s1600/container_explanation.png> >> >> >> >> <https://lh3.googleusercontent.com/-MJQw2yspEUE/V_tt0Bg3xPI/AAAAAAAAB8s/Z6txSatzpM83T_v0AqUvcQXvgitUuzS1ACLcB/s1600/container_explanation.png> >> >> Hey, >> >> Ok I spent the week-end trying to think about the pros and cons of this >> proposal. >> >> @XedinUnknown, I'm not sure I understood 100% of your proposal so I'll >> try to rephrase it. If I'm wrong, let me know. >> >> I understand you are trying to improve the "delegate lookup feature". >> Your goals are: >> >> - to make it "explicit" that a container is implementing the "delegate >> lookup feature" >> - to make it possible to nest containers at an unlimited level (to be >> able to nest a composite container in another composite container...) >> >> To do so, you propose to add a new interface named >> ParentAwareContainerInterface >> <https://github.com/XedinUnknown/di/blob/master/src/ParentAwareContainerInterface.php>. >> >> This interface is exposing a single method "getParentContainer()" that >> returns the parent container if any (i.e. the composite container >> containing this container). >> When resolving a dependency, the container goes up the chain of parent >> containers >> <https://github.com/XedinUnknown/di/blob/master/src/AbstractParentAwareContainer.php#L39-L55> >> >> until it reaches the root container. It uses the root container to look up >> any dependency (just like in the current delegate lookup feature). >> >> Here are a few thoughts about this idea: >> >> First: who is consuming the ParentAwareContainerInterface >> <https://github.com/XedinUnknown/di/blob/master/src/ParentAwareContainerInterface.php>? >> >> This interface is consumed by "child" containers. If a container is a leaf >> in the container tree (so if it is not a composite container), then there >> is no need for it to implement the ParentAwareContainerInterface >> <https://github.com/XedinUnknown/di/blob/master/src/ParentAwareContainerInterface.php>. >> >> The interface is trivial to implement and is a good declaration of intent >> (your container states it supports delegate lookup feature) but it is none >> the less useless. This interface is only useful for composite containers >> (so that they can also be bundled into parent composite containers). >> >> Second, each container now needs to find the root container by going up >> the container tree. In your sample, you do this while resolving a service >> <https://github.com/XedinUnknown/di/blob/master/src/AbstractParentAwareContainer.php#L64>. >> >> This is a bit of a problem performance-wise because this will slow service >> resolving (and this is a major no no for many implementors). Of course, >> there is a simple way around that. Finding the root container could be done >> only once, possibly in the constructor. This assumes that the parent >> container is passed to the child container constructor (or at build time). >> This also assumes that the parent container will never change in the life >> of a container (this is a safe assumption). Looking at @XedingUnknown code, >> this means that stuff like containers with mutable parents >> <https://github.com/XedinUnknown/di/blob/master/src/ContainerWithMutableParent.php> >> >> should be forbidden and only containers with immutable parents >> <https://github.com/XedinUnknown/di/blob/master/src/ContainerWithImmutableParent.php> >> >> should be allowed. >> >> If we assume that the "parent" container is always passed to containers >> in their constructor, it means that containers MUST be constructed in the >> order of the tree (from top to bottom). >> >> >> >> <https://lh3.googleusercontent.com/-MJQw2yspEUE/V_tt0Bg3xPI/AAAAAAAAB8s/Z6txSatzpM83T_v0AqUvcQXvgitUuzS1ACLcB/s1600/container_explanation.png> >> >> >> <https://lh3.googleusercontent.com/-MJQw2yspEUE/V_tt0Bg3xPI/AAAAAAAAB8s/Z6txSatzpM83T_v0AqUvcQXvgitUuzS1ACLcB/s1600/container_explanation.png> >> >> I made a picture so it would be more clear. If the "root container" >> exists before "Composite A" and if "Composite A" exists before "Container >> 1", then when "container 1" is created, instead of passing an instance of >> composite A, it should directly be passed an instance of the root >> container. That way, "container 1" does not have to go up the tree to find >> the root container. This makes the proposed "ParentAwareContainerInterface" >> useless, because finding the root container can be and should be done >> *before* the container is created. >> >> @XedingUnknown, I understand your concerns that the "delegate lookup >> feature" of PSR-11 is not backed by a solid interface. After careful >> consideration, I'm not sure your proposal of adding a getter really solves >> any issues (because we already can nest several containers). However, you >> are making clear that we never spoke about the way containers should be >> created (and who should come first between the parent and the child >> container). After thinking about your proposal, what is now clear to me is >> that the parent should be created before the children (and maybe we should >> stress that out in the META document). >> >> If I was to add another interface, it would more likely be a "container >> factory" (a la zend-expressive) that can create a container while passing >> the parent container in parameter: >> >> interface ContainerFactoryInterface { >> // A composite container could use an array of >> ContainerFactoryInterface to build containers, passing them the very root >> container. >> public function createContainer(ContainerInterface $rootContainer); >> } >> >> @mnapoli, @mweierophinney, any thoughts about this? Do you think we need >> to consider this or am I overtinking things? >> >> I think we also need to discuss more here the "delegate lookup feature". >> It is an optional feature, not backed by an interface and this is >> unprecedented in other PSRs (correct me if I'm wrong but I don't think >> other PSRs have similar optional features). To the rest of the members >> here, do you think we should do something special regarding this? >> Espceially, how should an implementing container advertise that it is >> supporting PSR-11 with/without delegate lookup feature? >> >> Best regards, >> David. >> >> >> Le vendredi 7 octobre 2016 18:58:51 UTC+2, Xedin Unknown a écrit : >>> >>> 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 >>> <https://github.com/container-interop/container-interop/pull/8>, 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?* >>> >>> * <https://github.com/XedinUnknown/di>* >>> *XedinUnknown/di <https://github.com/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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0fb84cf6-334c-407f-8f11-4d98bdc9cdae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
