On Wed, Aug 25, 2021 at 7:46 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 25/08/2021 11:02, Nikita Popov wrote: > > I'd like to propose the deprecation of "dynamic properties", that is > > properties that have not been declared in the class (stdClass and > > __get/__set excluded, of course): > > > > https://wiki.php.net/rfc/deprecate_dynamic_properties > > > This is a bold move, and in principle seems sensible, although I'm > slightly scared how many places will need fixing in legacy code bases. > > I have a couple of concerns with using stdClass as the opt-in mechanism: > > * The name of that class already leads to a lot of confusion about its > purpose - it's not actually "standard" in any way, and new users seeing > it as a base class are even more likely to mistake it as some kind of > "universal ancestor". Would it be feasible to introduce an alias like > "DynamicObject" which more clearly defines its role? > > * Adding a parent to an existing class isn't always possible, if it > already inherits from something else. Perhaps the behaviour could also > be available as a trait, which defined stub __get and __set methods, > allowing for the replacement of the internal implementation as you've > described? > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Although not having voting karma, I'm +1 on this. I've always preferred explicit over implicit code as it makes the learning path to newcomers a lot easier to grasp. When we talk about legacy code, more frequently than not is that legacy code is unlikely to run on the latest version of PHP, thus I'm not entirely sure if that's a super strong argument against it, but I may be missing something. -- Atenciosamente, Flávio Heleno
