Hey all! First of all, thanks for these early feedbacks!
@Rasmus: we are definitely not in a hurry and we can wait for your tests to see how your proposal go. Your comment is very interesting because you are pointing issues that would appear on massive projects. And indeed, when Matthieu Napoli designed the first version of container-interop/service-provider, I know for sure that this type of use case was clearly out of scope. This is why I believe the very first thing we need to do is to *discuss the scope* of this PSR. So far, the scope that Matthieu and I want to support is limited: Ultimately, we believe that container configuration is the responsibility of the application developer. Service providers (or application modules/bundles, etc...) are here to provide sensible default services. If the application developer has specific needs, then it's up to him configure the container and he probably should bypass the service providers altogether. For instance, a DB connection library like DBAL might provide a service provider to configure one DB connection (because it's a sensible default). If your app has 2 or 3 DB connections, and you want one provider to connect to one DB and another provider to connect to another DB, then we are out of the scope. It doesn't mean that you can't do it with the current proposal (I'm exploring the possibility to use "mappers" to rename/alias services in order to circumvent these limitations), but we are comfortable saying the scope of service-providers can be limited. The container is here to help the developer "wire" the services together. If the developer has to deal with wiring the service providers together (I connect this DB service provider to this Cache Service provider, etc...), I feel we are simply moving the problem we are trying to solve one level up the chain (wiring service providers instead of wiring services), but we are not actually solving the problem. Especially if you consider it is likely that most service providers will contain 1 or 2 services at most, the amount of wiring to do will pretty much be the same. I'm pretty much ok sharing a single namespace for all services (all frameworks are already doing this) Even with such a limited scope, there is place for discussion. For instance: can a service provider act differently based on the services/entries already in the container? (can a service provider provide a "CacheInterface" entry if and only if there is no entry for "CacheInterface" already defined?) etc... I'd be intereted in gathering comments from framework authors out there. Are you confortable with this scope? Do you think instead that we should cover a wider scope (as described by Rasmus?) ++ David. -- 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/99727206-a4ff-4d4b-9b03-1e5dae6714a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
