Hi Marco,
On Thu, Jun 27, 2024 at 12:32 PM Marco Pivetta <[email protected]> wrote:
>
> Hey Arnaud,
>
> On Wed, 26 Jun 2024 at 21:06, Arnaud Le Blanc <[email protected]> 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