Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116428
MIME-Version: 1.0
References: <CAF+90c_wDsjuMFAoQLehkn5GeoLv5GByczF+o-eDmYe+VVRxTA@mail.gmail.com>
In-Reply-To: <CAF+90c_wDsjuMFAoQLehkn5GeoLv5GByczF+o-eDmYe+VVRxTA@mail.gmail.com>
Date: Tue, 16 Nov 2021 16:20:58 -0600
Message-ID: <CAESVnVojL8FQLvQ7BMUA+dLaGQVdNHTZG=N88Azi6C5d0gCkbA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009cb4fd05d0ef578c"
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: pollita@php.net (Sara Golemon)

--0000000000009cb4fd05d0ef578c
Content-Type: text/plain; charset="UTF-8"

Serious questions for all the folks worried that this is some kind of death
nail for PHP.

1. Do you have code you're responsible for which uses dynamic properties so
broadly that adding this attribute is a burden?
2. Do you know of real code in widespread use which uses dynamic properties
so broadly that adding this attribute is a burden?

All I see being bandied about are hypotheticals.  So here's my answers: In
my entire career (which granted, is only about half actually written IN
php) I can point to exactly one class* which makes use of dynamic props and
it would take me a hot minute to add the attribute and commit it to the
repo (note: This code base is running on 5.x, so it doesn't need it, but it
can handle the attribute all the same).  I don't consider that hot minute
to be problematic.

For those wondering what's the point: Making the engine better is the
point.  We won't see the payoff in 8.2, or even 9.0, but by 10.0 we should
be able to be in a better place and have a better engine out of it.

-Sara

* Not counting uses of stdClass which is going to implicitly have this
attribute.

--0000000000009cb4fd05d0ef578c--