Re: [RFC] Deprecate dynamic properties
| From: | Ayesh Karunaratne | Date: | Wed, 25 Aug 2021 11:28:13 +0000 |
| Subject: | Re: [RFC] Deprecate dynamic properties | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115807@lists.php.net to get a copy of this message | ||
>
> Hi internals,
>
> 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 has been discussed in various forms in the past, e.g. in
> https://wiki.php.net/rfc/locked-classes as a class modifier and
> https://wiki.php.net/rfc/namespace_scoped_declares /
>
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md
> as a declare directive.
>
> This RFC takes the more direct route of deprecating this functionality
> entirely. I expect that this will have relatively little impact on modern
> code (e.g. in Symfony I could fix the vast majority of deprecation warnings
> with a three-line diff), but may have a big impact on legacy code that
> doesn't declare properties at all.
>
> Regards,
> Nikita
Hi Nikita,
Thanks for opening this, I'm very supportive of this.
Having some Drupal and other legacy background, I'm afraid this could
disrupt a lot of Drupal applications, which uses dynamic properties
quite extensively in its Entity APIs, Views, etc. I totally agree that
it is a bad practice, but that's what half a million or so Drupal 7
web sites do.
Perhaps, we can make it an easy to opt-in with a keyword (`locked
class Foo {}
) or an interface (Foo implements LockedClass {}`), or
provide an easy opt-out (similar to the tentative return type
attribute)?
Thank you,
Ayesh.