On Wed, Nov 17, 2021 at 5:35 AM Paul Crovella <paul.crove...@gmail.com> wrote:
> On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov <nikita....@gmail.com> wrote: > > > > Hi internals, > > > > I've opened the vote on > > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close > > 2021-11-26. > > > > Regards, > > Nikita > > In the Motivation section when talking about static analysis the RFC > makes the claim: > > > The #[AllowDynamicProperties] attribute proposed in this RFC makes the > cases where dynamic properties are used intentionally explicit. > > however this really isn't true as the attribute is on the class rather > than the use. Static analysis will still have no idea whether any > dynamic property assignment is indeed a bug or intentional. The > information added is only whether the author of the class has deemed > it okay for dynamic properties to be used on it, not by it. The class > author and the dynamic property user might not be the same person or > have any relation. The class being intentionally used with dynamic > properties is not necessarily in the user's control. Similarly the > class being unintentionally used with dynamic properties may not be > either. > There is an assumption in the design, that certain classes are designed to be used with dynamic properties, and all dynamic properties are acceptable in that case. This is basically classes that could be using __get/__set, but instead use dynamic properties for reasons of simplicity, performance or migration ease. If the class only works with a fixed set of properties then those should be declared instead, and if it has more complex constraints, then __get/__set can be used to implement arbitrary rules. (Setting dynamic properties on classes you do not own and that do not opt-in is explicitly unsupported under this model, with the recommendation to use WeakMaps for non-intrusive value association instead.) Regards, Nikita
