codenamephp / platform.di Goto Github PK

The interfaces like iContainer should have a default definition set that defaults to the container itself, pretty much like phpdi itself handles it

It's been a while since I put any amount of effort into this package (mostly because it still works like it's supposed to).

But some outdated stuff should be brought back up to speed:

• Remove Jenkins build and include travis
• #18
• Add Psalm, phplint, update to PHPUnit 9, ... all the good stuff
• Strict typing
• Maybe think about moving to composition instead of inheritance, there aren't that many methods to take care of
• Make classes final

Release Drafter should be added as workflow since it's very convenient.

When migrating to composition I forgot that addDefinitions (and maybe other public methods) might be in use and are not available in the interface anymore. Those should be added again and declared as deprecated if I don't want to support them in the future anymore.

There is a feature request to automatically add dependencies. Although I'm not a huge fan of it I understand the wish to only add the "top level providers" and have the dependencies added automatically.

• Create a new "RecursiveDependencies" collection
• Add the dependencies recurisvley before adding the provider
• Check if the dependency is already added (use a diff) before the recursion
• Create a provider factory interface to create the provider classes from the dependency class names to have at least some flexibility in how the dependencies are created
• Create a "SimpleNew" factory implementation and set it in the "RecursiveDependencies" constructor as default

After a release was created, the readme should be updated with the new tag in default branch as well as in the new tag itself.

There should be a way to auto configure libraries by adding a provider class to the builder.

1st step idea:

There a several provider interfaces, e.g. iGlobPathProvider, iDefinitionsProvider, ...

The current dependency check just collects the added dependencies in an array. If a provider is added its dependencies are checked against that array. If the dependency is missing an exception is thrown.

This has the advantage that the logic behind it is very easy and that missing dependencies are detected early. But it comes with the disadvantage that dependencies actually have to be added in the correct order which can be cumbersome when there a lot of providers and one might also group similar providers together for better readability.

One solution might be to collect the dependencies and then do a topological sort (possible candidate: https://github.com/marcj/topsort.php) before the container is built.

While comparatively complicated this would also have the nice bonus that the handling of the providers would have to be extracted from the container builder which is something I wanted to do anyway since adding a new provider type requires changes to the existing code and also makes testing more difficult.

Initial idea:

• Rework to collection system
• Rework ClassnamesInArray to new collection
• Add TopoGraph collection
• The existing ClassNamesInArray can basically stay the same in the way that it still adds and checks the depencies as they are added and the "build" step doesn't do anything

In addition to the autoconfiguraiton from issue #1 there should a way that the configurations are detected automaticly so they don't need to be added manually

array_diff would get rid of the if and make the function more readable.

The glob files should be discovered directly when they are added. Otherwise, they would always overwrite everything else as they are added last (on build).

Example:

$builder->addGlobPath(...); //would overwrite definitions in next line since the files are discovered and added later
$builder->addDefinitions([]); //would not overwrite definitions in glob

The container builder uses itself as class, not the container

It sometimes makes sense to spread definitions across multiple providers. To prevent having to add multiple classes or change the configuration when a new provider was added a MetaProvider interface that can add multiple providers at once would make sense

http://php-di.org/doc/migration/6.0.html

The dependency handling adds the class only if the iDependency interface exsists. If not, the class is never added to the existing dependencies. If another class depends on it the dependency can never be satisfied.

The class names of added providers should be recorder even if no interface is set. Otherwise, classes have to explicitly enabled to be dependencies which kind of defeats the purpose.

There should be a trait for the member and getter/setter using the iContainer interface