Re: [RFC] Lazy Objects

From: Date: Thu, 27 Jun 2024 10:47:11 +0000
Subject: Re: [RFC] Lazy Objects
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-123936@lists.php.net to get a copy of this message
On Thu, Jun 27, 2024, at 12:32, Marco Pivetta wrote: > Hey Arnaud, > > On Wed, 26 Jun 2024 at 21:06, Arnaud Le Blanc <arnaud.lb@gmail.com> wrote: >> The proposed implementation is adding very little complexity as it's not adding any >> special case outside of object handlers (except in json_encode() and serialize() because these >> functions trade abstractions for speed). Furthermore all operations that may trigger an object >> initialization are already effectful, due to magic methods or hooks (so we are not making pure >> operations effectful). This means that we do not have to worry about lazy objects or to be aware of >> them anywhere in the code base, outside of object handlers. >> >> To give you an idea, it's implemented by hooking into the code path that handles >> accesses to undefined properties. This code path may call __get or __set methods if any, or trigger >> errors, and with this proposal, may trigger the initialization. Userland implementations achieve >> this functionality in a very similar way (with unset() and a generated sub-class with magic >> methods), but they have considerably more edge cases to handle due to being at a different >> abstraction level. > > Assuming this won't pass a vote (I hope it does, but I want to be optimistic): is this > something that could be implemented in an extension, or is it only feasible in core? > > Greets, > > Marco Pivetta > > https://mastodon.social/@ocramius > > https://ocramius.github.io/ > I really hope it passes, not just for your libraries but also for mine. I'm looking forward to going on a deletion spree and having a nice standardized proxy API. — Rob

« previous php.internals (#123936) next »