Version 0.4 of the ongoing original proposal looks pretty solid to me by now.
The alternative proposal involves strings with PHP-like type-hints that need to
be parsed and checked at run-time. Seems a bit brittle, more complex than I'd
like, and doesn't really seem necessary.
The only thing missing for me, from the first proposal, is the ability for
providers to depend on providers, somehow. These past few years, I've been part
of building a big system at work - and we have so many providers now, with so
many dependencies, one of the most common problems is "hey, this provider gave
me some component that needs a dependency X, which other provider is supposed
to provide me with X?"
The second proposal seems to address the need to check for missing dependencies
up front - but what we'd really like, is a declarative means of saying "this
provider depends on that provider", since, almost 100% of the time, in an
environment where literally everything is bootstrapped by providers, the answer
to "X is missing" is going to be "Add the provider of X", rather than
"bootstrap X yourself".
Another common problem is the order in which providers get bootstrapped - if
one provider needs to override a registration of another, the order matters.
One idea to solve both of these issues, is to introduce a provider ID of some
sort. The provider's own class name would be an obvious candidate, though the
Composer package name might be a safer choice, since ::class might not provide
static analysis when a provider isn't installed.
So basically two methods:
function getProviderID(): string;
function listRequiredProviders(): string[]
The container can now get the full list of providers, use a topological sort to
figure out the correct order in which to bootstrap these providers, check for
missing providers, etc.
This enables "abstract" providers as well - for example, a provider might
depend on "psr/cache", which might be the Provider ID of numerous packages with
an agreed-upon ID and bootstrapping scope. This would build on the idea of
abstract Composer packages and make that concept more useful - since merely
installing a package (with correct version and dependcies etc) is all that
Composer can guarantee, this lets us guarantee that it's provider has also been
bootstrapped.
I think, at this point, that's the only missing feature for me.
--
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/8ce70deb-049b-407e-bf01-332440ab30ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
