Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115803
To: PHP internals <internals@lists.php.net>
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
Message-ID: <2c275aa7-f22f-70aa-283c-f6d22b8490bc@mobilejoomla.com>
Date: Wed, 25 Aug 2021 13:52:20 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties
From: denis@mobilejoomla.com (Denis Ryabov)

On 25.08.2021 13:02, Nikita Popov wrote:
> 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


I use dynamical properties in a legacy code for lazy object creation in 
the dependency container (with properties declared using @property 
phpDoc comment, so that PhpStorm IDE supports them). But in my case it's 
not a problem to refactor that code.

I'd suggest to consider "use stdClassTrait" (the name is just for 
example) as an alternative to "extends stdClass" and "implements 
stdClassInterface", because 1) It allows to further implement 
__get/__set in that trait, and 2) It's possible to don't require base 
abstract class to extend stdClass when dynamical properties are used in 
a child class only.