rebelcode / eddbk Goto Github PK

Getting this error when activating the plugin:

Plugin could not be activated because it triggered a fatal error.

It would be ideal if modules could dictate how their main class in instantiated, and ideally that would happen via the module's service provider. In the frame of our "module is gateway" paradigm, this may look odd; however, that's OK since service provider registration doesn't actually do anything.

With regard to how the module's service provider should be registered, I can say that this should happen in a structured way, and before the module instance is created, thus solving the recursion problem. Also, a module should be able to register multiple service providers.

Another point is the container itself. AFAIK, no conclusion has been made WRT whether we are going to have a hierarchical container structure. I support the idea of having composite containers, and if we do this, then maybe the module could be responsible for registering its providers on its own container, and we just hook it up. Perhaps, one of the ways is as follows.

The module configuration must specify an additional parameter with key container. The value would be a callable (perhaps in the form My\Namespace\containerFactory or My\Namespace\ContainerFactory::make). The callable must return an instance of ContainerInterface. It will also receive a ContainerInterface, and we assert that calling get() on this instance would allow retrieval of services in the returned container, unless they are overridden somewhere.
Under the hood, the passed instance will be the top-most composite container. The factory should make this instance available to its service factories, wherever they are, by any means possible. The module can use its own container implementation, whichever it wants. The module may or may not use the Service Provider standard, or the FactoryInterface. This is all the responsibility of the module. The module must declare dependency on the packages, which contain the DI tools that it wants to use, which may be the same package that the "main system" uses, in which case the deps will be compared and resolved by Composer, reporting incompatibility immediately if applicable.
We could also go the extra mile and allow the factory to return a ServiceProviderInterface, in which case a default container implementation will be used by us, and the module does not need to depend on any package that implements PSR-11.