On Wed, Aug 25, 2021 at 1:03 PM Nikita Popov <nikita....@gmail.com> 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 > Hello everyone, This is going to be a bit wordy, so sorry in advance, but I want to set the context correctly. As a userland developer, the overall idea concept I agree with, but the thing that irks me here is that this is opt-out. My day to day reality is dealing with complex big projects with codebases that go into 5 digit file numbers excluding the ./vendor folder. The projects are not legacy projects - they are being updated and are actually run on 7.4 in E_ALL mode, we just finished upgrading it to Symfony 5.3 and are going to go full PHP8 soon. There are parts of the project that are older style code and we update those as we go - we actually do have tasks assigned to team members to specifically update the code, so it's planned steady progress that has been going on for 2 years now. We are not a small dev team too, but we also have our tasks to do features, fix bugs and in general keep the system running and evolving. Most our code is strict_types=1 and PHP 8 ready. It is going to be a major undertaking that would halt all work to migrate to a newer version of PHP where we need to inject the allow dynamic attribute without hitting a brick wall. It is not even going to be us, the developers, who are going to have the biggest chunk of it - it's going to be the QA who are going to have to go through the whole project and identify all the issues that crop up. It is a complex and big piece of software that has been developed for the past 10 years - there is no easy way to do one-shot big upgrades without prior planning way in advance. And while we can certainly deal with it eventually (and stay on older PHP versions for a while) all the 3rd party packages that we use are going to be an even bigger pain to deal with and manage. If a 3rd party package combines fixing major bugs with a release of a significant version and including also the new attribute that's available only on newer PHP version? You end up in an "all-or-nothing" situation. I hope I do not have to explain why this is not good? This also goes against the general way PHP has been doing the strict stuff - you opt-in into typed properties, arguments and return types. You also opt-in into strict type mode. Feels like this should follow the same approach. If we are talking about having a blanket depreciation and then a fatal error like that, I feel like it should be part of the `declare(strict_types=1)` mode for the simple reason that most code in the wild is not really dynamic when the developer chooses to run in strict mode (and a few cases where they need it - the RFC shows good ways to convert the code). Meaning chances of things breaking in a major way and requiring a lot of work to update the code. Automated tooling is nice if you know you can safely do "all or nothing". In complex systems that are ongoing projects where you have to balance progress with upgrading older parts it's rarely that simple. Something to think about and my 0.02$ on the subject. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
