Re: [PHP-DEV] [RFC] Deprecate dynamic properties

This is only part of a thread. view whole thread
  115811
August 25, 2021 13:51 rowan.collins@gmail.com (Rowan Tommins)
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]
  115812
August 25, 2021 14:00 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Aug 25, 2021 at 3:51 PM Rowan Tommins collins@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. >
Isn't this a direct consequence of LSP? We can't just drop behavior when extending. Only way for this not to follow would be if we disallowed extending from stdClass entirely, which we presumably don't want to do.
> 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;" >
Yes, I can see the argument for aliasing stdClass to something more meaningful, even independently of this RFC. I'm not sure it will have a big impact for this use-case though, because using the new name would require polyfilling it, so I'd expect people would stick to the old name in the foreseeable future... Regards, Nikita
  115818
August 25, 2021 14:49 rowan.collins@gmail.com (Rowan Tommins)
On 25/08/2021 15:00, Nikita Popov wrote:
> I'm not sure it will have a big impact for this use-case though, > because using the new name would require polyfilling it, so I'd expect > people would stick to the old name in the foreseeable future...
Not necessarily - it depends what versions you need to support, and what your migration strategy is. Since it's just a deprecation notice initially, you could support 8.1 and 8.2 on the same code base with no changes at all - that's what deprecation notices are for, to give a lead time before changes are mandatory. Once the code base no longer needed to support 8.1, "extends DynamicObject" could be added. For many code bases, that will be long before the feature is actually removed - for a private project, maybe as soon as it's on 8.2 in production. Regards, -- Rowan Tommins [IMSoP]
  115813
August 25, 2021 14:04 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins collins@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. -- Chase Peeler chasepeeler@gmail.com
  115836
August 25, 2021 20:56 ramsey@php.net (Ben Ramsey)
--9T0kEoBqncr6QLdj4opjFb23AIhnDfYXp
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Chase Peeler wrote on 8/25/21 09:04:
> 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 thin= gs
> around it. It's not something that can be easily refactored since it wa= s
> part of the design.
Since the stdClass behavior is retained in this proposal, could you change your base classes to `extend stdClass`? Cheers, Ben --9T0kEoBqncr6QLdj4opjFb23AIhnDfYXp--
  115840
August 25, 2021 22:37 mike@newclarity.net (Mike Schinkel)
> On Aug 25, 2021, at 10:04 AM, Chase Peeler <chasepeeler@gmail.com> wrote: > > On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins collins@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
  115814
August 25, 2021 14:08 pierre-php@processus.org (Pierre)
Le 25/08/2021 à 15:51, Rowan Tommins a écrit :
> 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, > Hello,
And why not adding an extra keyword, such as: ``` ``` Regards, -- Pierre
  115815
August 25, 2021 14:18 internals@lists.php.net ("Levi Morrison via internals")
> And why not adding an extra keyword, such as: > > ``` > dynamic class Foo { } // Dynamic allowed > class Bar {} // Dynamic disallowed > ?> > ```
I am opposed. IMO it's not worth adding anything to the language to preserve this existing behavior other than allowing `__get`/`__set`, etc, which already exist for this purpose. Additionally, there are technical benefits to removing dynamic properties altogether, so I don't think we should "half" remove it. See https://wiki.php.net/rfc/deprecate_dynamic_properties#internal_impact.