Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116396
To: internals@lists.php.net
Message-ID: <6192EEDA.8050900@adviesenzo.nl>
Date: Tue, 16 Nov 2021 00:35:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] Deprecate dynamic properties
From: php-internals_nospam@adviesenzo.nl

L.S.,

As some of you may have seen, I posted a thread on Twitter a few days 
back referencing this RFC: 
https://twitter.com/jrf_nl/status/1459221549429542920

I've been asked to post the link to the Twitter discussion in this 
thread for visibility.

The Twitter thread generated, and is still generating, quite a lot of 
discussion, which I believe is a good thing and I'd like to thank 
everyone of you who has been actively participating in these discussions 
and has taken the time to read the various opinions.

The thread, however, is not specifically about this RFC, but more about 
the more poignant issue of the current pace of deprecations in PHP, the 
impact of the workload these cause for open source project maintainers 
and the stagnation I'm currently seeing in PHP open source releases and 
innovation as a result of this.

As I'm posting here now anyway, I'd like to leave the following feedback 
for your consideration:

 From what I've gathered from responses and the added "Motivation" 
section (thanks Nikita), this RFC is intended as a stepping stone 
towards eventually removing support for dynamic properties from PHP 
completely.
This only got cursory mention in the RFC and the RFC as it is, does not 
lay out a clear path towards that end-goal.

What I miss in this RFC - and also oftentimes in other RFCs over the 
past few years - are:
* The real reason behind this change proposal. "Modern code doesn't use 
this" is not a reason and also not always true.
* An impact and workload analysis for userland PHP code, no matter how 
tentative.
* Argumentation that this is the right stepping stone towards eventually 
being able to achieve the end-goal of removing support altogether and a 
tentative outline of what the path towards that end-goal will look like, 
both in timeline, next steps and (tentative) criteria of when it would 
be acceptable to take those steps.

Without the above, the RFC as it currently is, is IMHO just creating 
more busy-work without a clear path forward.

Please also take note that while this deprecation may not have much of 
an impact on applications which have full control over their server and 
the PHP version on which the code is run, as those have a) full access 
to server logs and b) can use tools like Rector to upgrade (once a 
Rector for this has been written), this is a whole different ball-game 
for open source.

As pointed out before, static analysis tools (once written) can help, 
but may struggle to analyse the code using dynamic properties correctly 
in all cases.

In the end, if this gets deprecated, the best way to find the potential 
problematic instances, is, like always, a test suite with near full code 
coverage to see all deprecations, but let's also be realistic: a full 
test suite is a luxury few open source projects actually have.

And even when a full test suite is available, and this is probably the 
most important problem I see: **open source libraries are generally 
building-blocks in a larger whole, where the library itself has no 
control over how their users are using the code, let alone have any 
indication of whether their users may be using or extending the library 
in ways which _rely_ on dynamic properties.**
This uncertainty may lead to "abuse" of the attribute to prevent 
introducing a breaking change.

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.

Let me finish by saying that I'm heartened to see the discussions here 
today, the addition to the RFC of the "Motivation" section and the ideas 
about a more gradual path, like mentioned by Derick and outlined by 
Larry and it gives me hope that the impact of these type of changes on 
OSS maintainers may be given more consideration in RFCs in the future.

With kind regards,
Juliette Reinders Folmer