Re: Re: [RFC] Deprecate dynamic properties

On 12/10/21 9:23 pm, Nikita Popov wrote: > Based on the received feedback, I've updated the RFC to instead provide an > #[AllowDynamicProperties] attribute as a way to opt-in to the use of > dynamic properties. As previously discussed, this won't allow us to > completely remove dynamic properties from the language model anymore, but > it will make the upgrade path smoother by avoiding multiple inheritance > issues. Especially given recent feedback on backwards-incompatible changes, > I think it's prudent to go with the more conservative approach. I think it would still be the biggest compatibility break since PHP 4->5. Adding a custom property is a common way for an extension to attach data to an object generated by an uncooperative application or library. As the RFC notes, you could migrate to WeakMap, but it will be very difficult to write code that works on both 7.x and 8.2, since both attributes and WeakMap were only introduced in 8.0. In MediaWiki pingback data for the month of September, only 5.2% of users are on PHP 8.0 or later. Also, in the last week, I've been analyzing memory usage of our application. I've come to a new appreciation of the compactness of undeclared properties on classes with sparse data. You can reduce memory usage by removing the declaration of any property that is null on more than about 75% of instances. CPU time may also benefit due to improved L2 cache hit ratio and reduced allocator overhead. So if the point of the RFC is to eventually get rid of property hashtables from the engine, I'm not sure if that would actually be a win for performance. I'm more thinking about the need for a sparse attribute which moves declared properties out of properties_table. I would support an opt-in mechanism, although I think 8.2 is too soon for all core classes to opt in to it. We already have classes that throw an exception in __set(), so it would be nice to have some syntactic sugar for that. -- Tim Starling