Attributes instead of interfaces

[roxblnfk]

Hello. It's nice to see the designing of PSR in a rational way.

Have you discussed marking factories with attributes, instead of declaring interfaces that return closures? In this case, even Symfony with their compiled container could squeeze the maximum out of it.

class ServiceProvider {
    /**
     * Define container ID
     */
    #[Factory(id: 'alias')]
    public function makeAService(Psr\Container\ContainerInterface $container): mixed {...}

    /**
     * Without ID the return type may be used
     */
    #[Factory]
    public function makeFooService(Psr\Container\ContainerInterface $container): FooService {...}

    /**
     * Despite your insistence that the closure should only take the container, 
     * people will still want autowiring. This is also great for compiled containers.
     */
    #[Factory]
    public function makeWithAutowiring(App\BarService $dependency): FooService {...}
}

Attributes can also be extensible. This way different implementations can add their own settings, but it will still be compatible with PSR. I haven't thought about how correct this is yet. I would most likely use a second attribute with some specific settings alongside.

[roxblnfk]

Ah, found it in early discussions.
#64 (comment)

However, note that this is the path that might not meet serious resistance from Symfony.

[mindplay-dk]

I am confident that you will find greater cooperation from the Yii3 side, at least I am pushing them towards it.

Alexander Makarov (samdark) has already expressed interest and participated in discussions. 🙂

So, if you manage to sway Symfony, everything will work out.

Symfony and Laravel will be much harder to sway.

I think, if we went ahead and built everything, including adapters for the major frameworks, and assuming the community showed interest, and packages started to ship with factory classes -- then they would have to at least address it, wouldn't they. 😏

But even if I built it all, I don't have the social media reach to make it happen. And it's a massive undertaking - I'm not sure I have the time or the energy to do it all myself.

I would love to be part of a working group though, so that's my hope. It's difficult to engage the right people to make that happen though. I'm just a guy with no name who happens to build stuff. 😄

[mindplay-dk]

I think that compiling the correct set of attributes is the most challenging task in the service providers designing.
Do you already have a draft list of attributes and their semantic descriptions?

sorry, missed that one 😉

no, the idea is quite new, I haven't spent much time on it yet - all I have is this rough draft but that was literally just 20 minutes of doodling, by no means a real design...

[roxblnfk]

Yes, I've seen that draft 👌
I think the Extend and Inject attributes are superfluous there, and it would be better to focus on what relates to factories and service providers.
Perhaps I am mistaken, but currently Extend and Inject look like answering "how to inject" instead of "how to produce"

[mindplay-dk]

@roxblnfk I don't know what you mean? When the component isn't a singleton (resolved by the type-hint alone) the container needs some way of knowing which service ID to inject - and for extensions, it additionally needs to know which service ID you're expecting to extend and replace. How would it work without these?

[roxblnfk]

@mindplay-dk Indeed 👌 When I was thinking about this, I fell out of the context of service providers and imagined that users would use these attributes in the code of their services 😃
Perhaps, it would be a good idea to limit the scope of attribute usage right in the RFC.

[mindplay-dk]

Thank you for your participation. 🙂

As you've discovered, we discussed this idea already - it is a cool idea, and I have some experimental code in a repository playing around with some ideas in this area myself.

I would certainly welcome experiments in this area - a service provider builder implementing patterns like these, I'm sure, would be a very cool proof of concept, and a very nice thing to have (and show) if this PSR comes to fruition! 👍

[roxblnfk]

I think we'll implement it in Spiral