Add support for native PHP 8.4+ lazy proxies. #917
Conversation
There was a problem hiding this comment.
Thank you for working on this, this is awesome!
Can you confirm that if I'm on PHP 8.4 and I use lazy loading, then it's going to use the native proxies automatically?
Could you update https://github.com/PHP-DI/PHP-DI/blob/master/doc/lazy-injection.md as well? (no need for a full rewrite, just making sure it's correct).
|
Looks like if I switch the logic so that anyone on 8.4 or newer uses native proxies, then that breaks a fair number of the tests because they're expecting the specific return type and signature of the Ocramius implementation. I'll work on getting those tests updated. May be a little more work than expected if we go that route. |
|
I updated the code to automatically enable native lazy objects for anyone using PHP 8.4 or newer, and I've updated the tests and docs accordingly. |
|
Looks like the last thing keeping it from being all green is that minor phpdoc positioning thing in a file I didn't modify (well, I did but I reverted it). |
|
ah I see, nevermind about that then (CS rule changes is annoying 😢), I need to take some time to review 👍 |
|
Thank you! |
PHP 8.4 introduced support for language-native lazy proxy creation, and as a result, Ocramius's ProxyManager is deprecated for users of PHP 8.4 and above in favor of these native lazy proxies.
This PR adds an option to the
ContainerBuildercalleduseNativeLazyObjects. The naming convention is taken from the Doctrine ORM's migration to native PHP lazy objects.The existing Ocramius
ProxyFactoryis still intact and unchanged for users opting not to use the new functionality. Its class has been incorporated into aProxyFactoryInterfacethat exposes common methods between it and the newNativeProxyFactoryclass. As some portions of the callable that was sent to the ProxyFactory were specific to Ocramius' proxy manager, these portions have been pulled up to that specific class in favor of a generic object builder callable that works with both services.New integration and unit tests have also been created to ensure the functionality of the new code.
The only BC break expected from this change is that the
Containerclass now expects aProxyFactoryInterfaceinstead ofProxyFactoryitself, which will affect any custom wrapping container classes. Otherwise, no other BC breaks are expected.