-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[VarExporter] Leverage native lazy objects #59890
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[VarExporter] Leverage native lazy objects #59890
Conversation
ae65a7a
to
3b27972
Compare
0bbd405
to
7badfb5
Compare
This comment was marked as outdated.
This comment was marked as outdated.
9852544
to
1d14933
Compare
1d14933
to
aaf3d4a
Compare
Self-review:
Status: needs work |
Be careful. Doctrine ORM 2.x is not EOL yet and it already supports using var-exporter (but will probably not receive a backport of the support for native lazy objects). This might impact the deprecation plan. |
6b9b1fd
to
e382b2f
Compare
I don't think this should impact us: ppl have a way to fix the deprecation: upgrade. The day where 2.x will be EOLed is close anyway. After many error-n-trial, I just pushed what I think is the implementation that works. First I thought we could use hooks to proxy all properties, but it happens those are not really compatible with references, so that we have to keep using magic accessors to proxy them. Status: needs review |
e382b2f
to
3c5d516
Compare
3c5d516
to
a00855a
Compare
Let's leverage native lazy objects.
Instead of keeping/updating LazyGhostTrait and LazyProxyTrait, I'm deprecating them in favor of using native lazy proxies directly.
There is one use case that is not covered by native lazy objects: lazy decorators - aka lazy proxies built against an interface or an internal class. For this use case, we keep
ProxyHelper::generateLazyProxy()
.