Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116337
Message-ID: <6e2d3e92-b53a-8264-85c6-d2d0062ee449@gmx.de>
Date: Sat, 13 Nov 2021 01:13:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Content-Language: de-DE
To: Matthew Weier O'Phinney <mweierophinney@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
References: <CAF+90c_wDsjuMFAoQLehkn5GeoLv5GByczF+o-eDmYe+VVRxTA@mail.gmail.com>
 <CAJp_myU5Wc3heD0vB7P8a65x4zd2pBmh9jt8Jb38SP80Kz0JSQ@mail.gmail.com>
 <f6c83821-e3f1-422b-914b-a26c7c64b934@www.fastmail.com>
 <CAJp_myVPsGY023o6+qMYu95M8fBdtGMzyh7xf_NJZhisKZc7bA@mail.gmail.com>
In-Reply-To: <CAJp_myVPsGY023o6+qMYu95M8fBdtGMzyh7xf_NJZhisKZc7bA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 12.11.2021 at 23:34, Matthew Weier O'Phinney wrote:

> On Fri, Nov 12, 2021, 3:41 PM Larry Garfield <larry@garfieldtech.com> wr=
ote:
>
>> The original version of the RFC would have (as of v9) allowed for the
>> removal of some fugly code in property handling, resulting in engine
>> improvements and some minor performance benefits.  That was because it
>> pushed the opt-in mechanism to "only if you extend stdclass", and stdcl=
ass
>> would effectively have a trait with stock __get/__set implementations t=
o
>> handle dynamic property behavior.  (It wasn't quite that, but effective=
ly
>> that's what it would do.)  So that was the original impetus.
>
> None of that information was in the RFC. That sort of thing really needs=
 to
> be included, as it helps a ton in justifying changes of this nature. As =
I
> noted, on reading it, the only rationale made is a quick mention that th=
ey
> lead to programming errors, and even then, there's no detail really if
> _how_.

At some point, the RFC explained some of the internal implications:
<https://wiki.php.net/rfc/deprecate_dynamic_properties?rev=3D1629900759#in=
ternal_impact>.
 To give one example: <https://3v4l.org/f8OZj>; no that's not a memory
leak, but rather the effects of materializing the properties HashTable.

However, since the attribute solution, which already was a compromise to
mitigate the BC break wouldn't make it possible to drop
zend_object.properties and friends, this reasoning was removed.  I still
hope that we can get rid of this ugly stuff eventually.  Obviously, that
requires to educate people and to push code bases "softly".  Offering an
opt-out of dynamic properties or some switch to disable the deprecation
would not help in that regard.

That "leading to programming errors" is about userland code.  Mistyping
the property name might not even be noticed during development/QA, but
may cause serious issues in production.  Of course, a static analyzer
would report this issue, but there is code where you'd have a hard time
to get PHPStan level 0 or Psalm level 8 working (and baseline wouldn't
catch existing issues).  Oh, and well, we're actually talking about code
which is not statically analyzed (or only at a very low level) anyway,
don't we?

> I'd like for a discussion on how we can allow the language to develop
> without requiring yearly churn and burden on the surrounding ecosystem. =
And
> just waving your hands and saying deprecations aren't errors is not an
> answer - if it makes its way to an error log or is reported inline in a
> page or in CLI output, it's an error.

I'd argue that it is not.  There are different levels of errors, and you
should likely treat them as such.  An error or exception is more severe
than a warning, a warning is more severe than a notice, and a
deprecation is yet different again.  You can ignore the latter, if you
don't care about the next PHP major yet; you can actually exclude them
from any kind of error reporting, until you care enough about them to
resolve them.  Even libraries could add a "suspended" ("won't fix
*now*") label to respective bug reports (and re-open when the time has
come).

Anyhow, I'm fully aware that PHP is pushing for years now.  As far as I
know, COBOL did not.

=2D-
Christoph M. Becker