Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116399
To: internals@lists.php.net
Date: Tue, 16 Nov 2021 03:39:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
References: <6192EEDA.8050900@adviesenzo.nl>
In-Reply-To: <6192EEDA.8050900@adviesenzo.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] Deprecate dynamic properties
From: marandall@php.net (Mark Randall)
Message-ID: <php.internals-116399@news.php.net>

On 15/11/2021 23:35, php-internals_nospam@adviesenzo.nl wrote:
> Either way, in my estimation, handling this deprecation will - again - 
> require not insignificant dev-time from maintainers to determine the 
> best course of action for each flagged instance and to implement the 
> changes, and what with the stagnation in OSS already happening, I wonder 
> if now is the right time for adding this to their work-load, especially 
> with the relatively flimsy argumentation for this RFC.


Can you approximate how much time you expect this to take?

Adding #[AllowDynamicProperties] to the top of each class seems like it 
is unlikely to be something that would take much time, and will almost 
certainly be catered for by automated tooling such as Rector before too 
long. Even without such tools, it could be applied by hand to hundreds 
of files in under an hour. Do you have a reason this is not the case?

Of course, the downside to this is that by doing so it may cover up 
existing bugs that this change is meant to help identify.

A distinction must be drawn between changes that MUST be made to be 
compatible, and changes that SHOULD be made because your code is 
carrying tech debt.

I would be interested in hearing how much of the workload you are 
experiencing falls into each category.

...

To cover the other point which is more subjective:

The inability for certain open source projects to keep up should 
absolutely not be a reason for PHP to slow down its development.

While OSS library projects are certainly important to the ecosystem, 
they represent a tiny fraction of the code that is written, and are 
often constrained by a small number of contributors to work on them, 
often times only a single person.

Should millions of other developers be held back because of the weak 
foundations of certain OSS projects? I think to do so would be a 
collosal mistake.

Yes, that means that some of these projects will not be able to do 
what's necessary and will fall into disrepair and be abandoned. I 
personally consider that an acceptable loss when compared to all the 
benefits these changes bring.

We must look to the future, for every line of PHP code that has ever 
been written, it's likely that there will be hundreds if not thousands 
of additional lines that will be written in the future, many of which 
will by people who have never written a single line of code before, in 
any programming language.

For that reason it is essential that PHP's out-the-box experience is 
sane and safe(ish) by design, and that means that common-sense defensive 
coding mechanisms should be the default, not something that you have to 
opt into, even if that means that old code will need to be modified to 
be compatible with those measures.

To do otherwise would be entirely unethical.

--
Mark Randall