I like the feature and I know the As prefix for these attributes is common in symfony, but I wonder a bit about the semantics. Usually if I see a AsSomething attribute on a class, it means that the class with the attribute now is a Something. When null is passed as the class to the factory argument, the semantics are fine. But if you provide another classname, a service or even expression language, the As prefix seems semantically incorrect to me, because now it is not the class with the attribute that becomes the factory, but something else. So in the first place I would suggest to rename the Attribute to just Factory.

But thinking about it a bit more: I believe it would be a better option to reuse the existing Autoconfigure attribute, which has a constrcutor argument, that can be used for factories in the same class. At the moment it only allows a string, referencing a static method inside the same class. You could simply apply your logic on the existing attribute argument if it is an array.

Hi @zolex, thanks for your comment ❤️ I really appreciate it 😄
You're absolutely right, the semantics of the As prefix can be misleading, especially when an external factory is used. Renaming the attribute to just Factory makes a lot more sense.
I also really like your suggestion about reusing the existing Autoconfigure attribute. I’ll work on updating it to support arrays and apply the logic there as well.
I’ll make these changes as soon as possible. Thanks again for the valuable feedback! 🙏

I was thinking a bit about this, and I have a question 🤔
If we change the constructor argument to accept string|array|null, I believe we would end up with the same behavior as the factory.
So, my question is: maybe we can leave the constructor argument as it is today, and instead, add the factory argument to the AutoConfigure?

I’m asking this from a place of curiosity and ignorance, totally open to discussion if I’m missing something 🙂
Thanks! ❤️

I was thinking a bit about this, and I have a question 🤔 If we change the constructor argument to accept string|array|null, I believe we would end up with the same behavior as the factory. So, my question is: maybe we can leave the constructor argument as it is today, and instead, add the factory argument to the AutoConfigure?

I would definitely prefer the argument to be called factory. If you introduce a factory argument, maybe also support a string for a method in the same class like constructor does and at the same time deprecate the constructor argument to prepare the people to migrate to the factory argument. It was a bad naming anyway.

I like that idea 😄 If others agree, I can go ahead and make that change:

• Add a new argument called factory
• Deprecate the constructor argument to help people migrate smoothly