On Thu, Aug 26, 2021 at 3:34 AM Nikita Popov <nikita....@gmail.com> wrote: > > The crux of the issue is what our end goal is: > > 1. Require users to explicitly annotate classes that use dynamic properties, > but otherwise keep dynamic properties as a fully supported part of the core language. > That's how I initially read your RFC, what I'm hearing here is that your quite explicit goal is:
> 2. Remove support for dynamic properties entirely. The core language only has > declared properties and __get/__set, and nothing else. stdClass is just a very > efficient implementation of __get/__set. > If that's your position, then the `extends stdClass` approach makes sense, because the dynamic properties HashTable can live in the object's extra data offset block and the get_prop/set_prop implementations in stdClass' handlers are the *only* things which know about dynamic properties. That represents a significant advantage to the engine for the "happy path" of declared properties only. Every (non-dynamic) object is a word (8 bytes) leaner, and the branch points for dynamic property access are limited to the only place they can be used, and where the typical result is positive. Starting from that argument, your RFC begins to look more compelling. I was definitely not starting there on an initial read. I do still have reservations about enforcing stdClass as a root for any class which wants to use dynamic properties. It's messy, but... to paraphrase what you said about going with an attribute approach... yeah, someone could make every current root class in their application explicitly inherit from stdClass without any ill effects in PHP < 8.2, with only the exception of external libraries being a problem. So that's the spectrum: - Opt-in to strict behavior: No BC impact, least benefit to the ecosystem or the engine - Attribute/Interface opt-out (goal#1): Moderate BC impact, ecosystem benefits well, engine benefits a little, but not much. - Extend stdClass opt-out (goal#2): Highest BC impact, ecosystem and engine benefit most. Goal#2 is bold. Possibly not-too-bold, but it's not clear to me where dynamic props are being used today and how many of those places can't "just extend stdClass" for one reason or another. Goal#1 might be a stepping stone along the way to Goal#2, as it will give us something clear to scan for across major frameworks at the very least, but that is going to push us from removal in 9.0 all the way out to removal in 10.0. If you're keeping track, that's gonna be circa 2030 give or take a year or two. That might be dangling the carrot out a little too far... The purist in me wants to be bold. It also wants some hard data on existing usages. A simple grep isn't going to cut it this time. We're going to need to run some static analyzers on some frameworks and libraries. Who's got it in them to do the research? -Sara
