Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Make resource factories meaningful #29133
App\Foo: resource: '../src/Foo/*' factory: App\Foo\MyFactory:create
The factory will not know which service it is supposed to create because it does not know which class it was invoked for. That is: there is no way to pass the class name to the factory.
I expect someone to point out that we can just create a factory for every class. Notwithstanding the resultant class explosion, in my particular case, writing a "generic" factory makes sense because all instances of this type can be constructed using reflection to map the name of constructor parameters to request attributes and/or query parameter names. This would save having to create many factories, but the missing link is informing the factory which class it's supposed to be constructing.
factories can receive arguments (if you defined arguments in a service definition using a factory, they are argument for the factory method, not for the constructor, as the container won't use the constructor by itself).
be careful about that. The container has a longer lifecycle than the request. There might be no request at all available when the service gets instantiated, and there might be multiple requests handled by the kernel (and your service won't be recreated for each of them). This sentence makes me think that these classes should probably not be defined as services (or should be re-architectured first, which would remove this use case).
Hi @stof. I was able to achieve it quite easily with a simple compiler pass to copy the class name from the definition into the argument.
I appreciate your warning about the container lifecycle. However, there is no use case in our application for handling multiple requests. Nevertheless, I completely take your point, and have recently reflected on the idea that the DIC does not seem suitable for building things that rely on runtime data. The factory pattern facilitates creating services that rely on runtime data, but since these services are shared (created once), then as you point out, they could represent obsolete data at a later time. Unfortunately, I don't know a better way to architect this, but mixing runtime (dynamic) and compile time (static) data in the DIC is definitely proving to be a source of difficulty for me, not least of all because it does not seem designed to do this.
I even have "services" called CurrentX, like CurrentAuthenticationToken, that are constructed using runtime data from the