Path constrained reflection container
mnavarrocarter opened this issue · comments
Hi there!
I've implemented for one of our company projects a modified version of the reflection container provided in this library. What you can do is provide to the reflection container a set of paths, and will only autowire definitions of classes inside those paths.
As you already know, this makes necessary the use of reflection on the has method, which makes this container a reflection-heavy container. To mitigate this, I also added a reflector cache, so we don't ask for reflection instances already created.
It think it works great and I was wondering if you would accept a PR with the new Reflection Container. I can either implement it modifying the original one (since is a BCC), or as a different PathConstrainedReflectionContainer (maybe).
I actually really try to discourage people from using the reflection container for anything other than fast prototyping so I'm not sure I'd want to add any optimisations to it.
I'm also not sure how much of an optimisation this would be, especially when taking opcache in to consideration.
Feel free to benchmark if you want to as I'd be interested to see the difference, but unfortunately I can't make any promises about something like this being accepted.
Also note: items resolved via reflection are already cached.
Yeah, I understand. I also don't use it unless I'm (1) executing a long-running PHP app as it's own web server and (2) needing to autowire http middleware/handlers located in very specific folders.
I think I can work with my own implementation. If you don't see it as a good feature to have, that's okay with me. :)