> On Aug 25, 2021, at 10:04 AM, Chase Peeler <chasepee...@gmail.com> wrote: > > On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins <rowan.coll...@gmail.com> > wrote: > >> On 25/08/2021 13:45, Nikita Popov wrote: >> >>> We obviously need to keep support for dynamic properties on stdClass, >>> and if we do so, I would expect that to apply to subclasses as well. >> >> Does that actually follow, though? Right now, there is no advantage to >> extending stdClass, so no reason to expect existing code to do so, and >> no reason for people doing so to expect it to affect behaviour. >> >> >>> Second, I consider "extends stdClass" to be something of a last-ditch >>> option. If you encounter a dynamic property deprecation warning, you >>> should generally resolve it in some other way, and only fall back to >>> "extends stdClass" as the final option. >> >> >> That's a reasonable argument in terms of the multiple inheritance case. >> >> My concern about the name remains though: people already do get confused >> by the name "stdClass", because it's not in any way "standard", and >> tells you nothing about what it does. >> >> Reading "class Foo extends stdClass" gives the reader no clues what >> magic behaviour is being inherited; "class Foo extends DynamicObject" >> would be much more clear. Similarly, "$foo = new DynamicObject; >> $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" >> >> Regards, >> >> -- >> Rowan Tommins >> [IMSoP] >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >> > Please don't do this. Call it bad coding practices or not, but this was > something I've considered a feature of PHP and have actually built things > around it. It's not something that can be easily refactored since it was > part of the design.
While I tend to really object to BC breakage, when I saw this proposal I was all for it because it disallows a practice that I have seen used all too often in cases where there was no good reason to not declare the properties, and I know that to be fact because the cases I am referring to are ones where I refactored to use declared properties. That said, I'd be really interested in seeing use-cases where having dynamic properties is essential to an architecture and where it could not be easily refactored. I cannot envision any, but I am sure that I am just limited by the extent of my vision and so would like to know what those use-cases would be. --------- Speaking of, it would seem like if dynamic properties were to be deprecated PHP should also add a function that would allow registering a callable as global hook to be called every time ANY object has a property dynamically accessed or assigned — conceptually like how spl_autoload_register() works — so that developers could run their programs to see what properties are used. The hook could collect class names, property names and data types to help developers who need to update their code discover the information required for their class declarations. Because doing it manually is a real PITA. As would be adding __get()/__set() to every class when you have lots of classes and you'd need to delete all that code later anyway. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
