Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116386
MIME-Version: 1.0
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
In-Reply-To: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
Date: Mon, 15 Nov 2021 20:27:08 +0200
Message-ID: <CAL0xaBGNn8uNLvf7UKdMgcHiNfMbw2nod1EtD9pYwdeQKJxOsg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000078edae05d0d7f64f"
Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000078edae05d0d7f64f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 25, 2021 at 1:03 PM Nikita Popov <nikita.ppv@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-langu=
age-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 warnin=
gs
> 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=3D1 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=3D1)` 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.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--00000000000078edae05d0d7f64f--