Hi Levi, On Wed, Jun 26, 2024 at 12:07 AM Levi Morrison <levi.morri...@datadoghq.com> wrote:
> I will vote no on this one. I do not believe the internal complexity > and maintenance is worth the feature. Additionally, I do not feel like > changing the language to support this feature is a good idea; if this > were a library only thing, I would not care. > Hi Levi, 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. Best Regards, Arnaud
