mnapoli
commented
8 years ago Hi, thanks for the feedback!
but that kind of misses the point of choosing one of these simpler containers - which was to get simplicity
I think you are missing an important point: this standard is only meant for modules. It isn't meant to be used by end users (i.e. in an application) or by frameworks. So there is still a point of choosing simpler containers. If end users want to use Pimple, they will not be affected by the "twig module" or "doctrine module", etc. They'll still use Pimple as they do today, and won't care about definition-interop while enjoying its benefits.
So yes this is a bit of an additional burden for module developers, but only for them, which could be considered OK.
However you might already be aware of it but we are now working on standard service providers instead of this project. And the main reason is exactly because it's much simpler for everyone. So maybe you'll be happy to hear about that.
it almost seems like there's no real point in making everyone go out and implement the interfaces in the first place.
That's also a conclusion I've reached. While trying out definiton-interop I realized using implementations could be simpler, as in the end assembly because kind of the "de facto" implementation when one needed one. I never bothered raising the issue here because this project is currently frozen in favor of the service-provider.
I'd like to see what an implementation for e.g. Pimple would look like.
Have a look at the container in assembly for example: https://github.com/mnapoli/assembly/blob/master/src/Container/Container.php But yes we did implement support in several containers, it was overall quite easy, but service-provider was easier in my experience.
I think in order to proove this idea, it's important to demonstrate that this can be implemented, and has some kind of value or purpose, even for containers at the opposite end of the complexity spectrum.
Definitely agree.
Reviewing this, two things occur to me.
First, it appears that the specification is largely an interface indirectly extracted from (or based on) the interfaces of a few popular implementations.
What about simpler containers, such as Pimple or my own Unbox?
I mean, you could of course create adapters, which would simply discard all the extra information and structure embedded in these models, but that kind of misses the point of choosing one of these simpler containers - which was to get simplicity. Now you're getting the same amount of complexity for something that was designed to be much, much simpler.
In other words, I need to provide all this extra information and structure to satisfy the more complex containers. That seems to favor the more complex containers, which seems somewhat opinionated?
Secondly, if the interfaces are going to contain this much detail and structure, it almost seems like there's no real point in making everyone go out and implement the interfaces in the first place. If everyone is going to be implementing largely the same thing to make their container work the same way, why not simply provide an implementation instead of a set of interfaces?
Maybe I'm missing something?
I'm take it you've been experimenting with implementations for containers that actually support things like parameters and factory call definitions as objects?
I'd like to see what an implementation for e.g. Pimple would look like.
I think in order to proove this idea, it's important to demonstrate that this can be implemented, and has some kind of value or purpose, even for containers at the opposite end of the complexity spectrum.