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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
