Taking a look at other languages

[moufmouf]

Since we are reviving this project, I thought it would be interesting to see how other languages do things nowadays.

Taking a look at Java, I found this "CDI" thing that seems to be tied to JSR-365.

https://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#declaring_producer_method

It is a "@produces" annotation that can be tied to a method or property to say the method acts as a factory.
I'm pretty sold to the idea (as I already said here: #60 (comment) , I believe it is worthwhile exploring)

I don't know how other languages do things, but it could be good taking a look.

[mindplay-dk]

Interesting, but isn't this another one of those somewhat opinionated approaches that could just as well be implemented by a service provider "builder" on top of the interoperability layer?

As I've written in my current PSR meta document draft:

The service providers defined by this PSR are intended as a "lowest common denominator" format. They are NOT intended to compete with or replace the developer experience of using service providers in full-featured DI containers and frameworks.

Rather, the goal is to achieve interoperability between various containers and frameworks. This could be achieved by:

• DI containers implementing support for consuming and exporting PSR service providers.
• Dedicated "service provider builders" which provide more convenient and opinionated APIs, and generate PSR service providers.

While hand-authoring PSR service providers is possible, the expectation is that developers will use the service definition facilities native to their preferred container or framework, while interoperability will be achieved behind the scenes through support for PSR providers.

The choice of which container and provider implementations to use for application services is left open to developers.

While I very much like the idea of potentially using attributes in various ways, I don't think an interoperability layers needs to consider anything more than the "lowest common denominator"?

I think we're very much on the right track, staying away from anything that could be construed as "opinionated" or "unncessary" - if we stay true to that mission and stick to the absolute bare fundamentals, I think this PSR will stand a better chance in the wild.

One of my early misconceptions about this PSR, was that it would somehow "erase" the meaningful differences between DI containers. Allowing the PSR to be "obviously bad" for anything other than interoperability might reduce the chance of it being seen as a "bad alternative" to DI containers, which tbh is how I saw it for a while, 6-7 years ago. 😅