>
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
