On Tue, Nov 16, 2021, 00:36 <php-internals_nos...@adviesenzo.nl> wrote:
> 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. > If memory serves me right, Nikita planned to always leave dynamic properties bound to a single class (possibly stdClass as it is its natural use). That would have allowed for performance improvement on the engine. However, as we've seen from the Serializable RFC, planning out a 2-major change means voting today for a change that will only take place in 10 years. That's too long of a time to predict whether the change being voted even makes sense. As it currently stands, I believe the RFC outlines the best it can do with the context in which we are. If nothing else ever happens in the matter, we're left in a better place anyway. > 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. > I see a pattern in these discussions from two mindsets: one thinking about how we should design the future and another thinking about how we preserve the past. In the past static analyzes wasn't even a thing in PHP. Nowadays we produce code that is much more likely to be analyzable in the future than a decade or two ago. The camp of people that has to deal with code that "is better left untouched" will often find these type of RFC lacking in motivation i.e "why are you making me touch that code that I don't want to touch or shouldn't have to touch?". Likewise the people that has already suffered through these code and want to prevent them from being a constant problem will need little convincing that the change is good. > 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. > I know you didn't mean it that way but I can't help but interpret this as a great motivation on why this RFC should be approved. It allows for a world to exist (in 3 years) where such a problem would be drastically reduced. New code will be more statically analyzable even if only to check whether dynamic properties are allowed or not and it will create a better atmosphere for better changes. > > > With kind regards, > Juliette Reinders Folmer > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
