Hi Matthew! I am very happy to see that there are already examples of what I meant! And yes, you got it right - the application container rules them all! But this is more of a typical use case, rather than a rule. We are discussing a standard, so I believe that we shouldn't limit usage to specific techniques, but only introduce a helpful concept, codified via an interface in this case.
With regard to usage outside of the service definitions, I'm afraid it's quite hard to come up with an example. However, what I really meant was that no matter why the consumer may need to do that, this approach would allow them to, since it represents the new concept. One example could be of a module that may optimize or otherwise re-arrange the container hierarchy. On the other hand, we can never know what the usage may be, and what patterns may emerge from our standard. We would simply support the "hierarchy" concept via language means. I think that a standard, while required to take into account specific use cases (and it appears that FIG makes its goal codifying the most common ones) must not limit implementations to those use cases, but instead simply provide a (perhaps language-supported) means of implementing these use cases, while keeping the door open for any other uses. For example, we could name the interface `DelegateLookupContainerInterface`, and it would serve its purpose; but would limit the implementation semantically to only lookup delegation. On the other hand, `ParentAwareContainerInterface` would allow simply a representation of any container hierarchy - maybe for use as a result of parsing an XML document (a DOM of sorts), or to represent a chart, or to delegate service lookup. I don't know what use cases there may be, and am not asserting that my examples are practical. Just expressing my point of view on the concept of "standards". Bottom line is that I saw the need for an interface in the standard, and came up with an example of what could work, as well as of how it could work. I am now unsure whether the community recognizes this need need, after the comments of @mnapoli What do you think about it? P.S. Sorry for the delay in response, very busy week. 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 > <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/799e978d-e508-4f1c-8ab3-58d4ee7bfaa4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
