Hi Marco, On Thu, Jun 27, 2024 at 12:32 PM Marco Pivetta <ocram...@gmail.com> wrote: > > Hey Arnaud, > > On Wed, 26 Jun 2024 at 21:06, Arnaud Le Blanc <arnaud...@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?
An extension could achieve similar behavior by decorating the default object handlers. However, it may have to re-implement a significant part of the object handlers logic, so that initialization is triggered at the right time. Best Regards, Arnaud
