Re: [RFC] Deprecate dynamic properties

  116396
November 15, 2021 23:35 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
  116398
November 16, 2021 00:21 deleugyn@gmail.com (Deleu)
On Tue, Nov 16, 2021, 00:36 <php-internals_nospam@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 > >
  116406
November 16, 2021 10:22 phpmailinglists@gmail.com (Peter Bowyer)
Hi list,

On Tue, 16 Nov 2021, 00:21 Deleu, <deleugyn@gmail.com> wrote:

> 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.
I would frame that differently as those who 1. Predominantly write new code (most of us on this list I expect) 2. Use ecosystems written in PHP (talking from personal experience I have WordPress and Drupal in mind, but I see it with Laravel and to a smaller extent Symfony users too). Both approaches are massive audiences for PHP and both have different needs. For the second group, finding that something you built on no longer works because "PHP changed" is a problem, in a way it isn't for members of this list, who would likely fork and fix it. It's easy to use the glib response that "it's open source, they should get their hands dirty" but for many, knowing how to get started is a barrier that stops them. Making a big generalisation, this audience is hugely proud of what they do manage to accomplish and can be hugely vocal proponents for PHP (ecosystems). Yet it's not always lack of knowledge either that makes small backwards-incompatible changes a problem. If you're a small business your focus is elsewhere and what those working at larger and highly profitable or well funded companies see as a small expense (however annoying) is a big loss of other opportunities that a small business could use to grow. I see this with some clients, where a day is a big deal, and a day spent testing an upgrade is a day not spent fixing the problem 5% of customers have. I take it as read that we want to continue serving both audiences. On improving PHP, there is a prevalent view on this list that the competition is people going to other programming languages. The hidden competition is people saying "keeping up isn't worth the effort" and switching to centralised SaaS offerings. We see all the good reasons for doing this playing out in our own "Switch to GitHub Issues" discussion. It's happening enough, we don't need to encourage it. Returning to this RFC it may surprise people that I like the idea of only having dynamic properties on stdClass & children. I don't go as far as saying "this is how it should have been from the start" as the culture was different when classes were introduced to PHP. But dynamic properties have been around since the start and I am wary of deciding to remove them in PHP 9. Kind regards, Peter
  116399
November 16, 2021 03:39 marandall@php.net (Mark Randall)
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
  116517
November 25, 2021 21:35 Danack@basereality.com (Dan Ackroyd)
Hi Juliette,

On Mon, 15 Nov 2021 at 23:36, <php-internals_nospam@adviesenzo.nl> wrote:
> > 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,
I'm not going to quote from the Twitter thread partly as lot of that discussion isn't that pleasant. To be clear, this change isn't being proposed to annoy open source maintainers, it's proposed because people think it will make the language better, to a great enough value to be worth the BC break. But also, a lot of that thread is about the experience of being an open source developer is absolutely terrible due to many factors including: * an almost complete refusal of companies to sponsor work. * people who work for companies that use open source having an attitude of entitlement to 'gold level support', and will very quickly start using emotionally manipulative language e.g. "if you cared about this project you'd work harder on it". * a lack of new contributors to open source. I completely understand how all of things are pretty aggravating. It's particularly galling when a maintainer tries to get some funding, e.g. by holding back a release targetting a new version of PHP, other people will undermine that effort by forking the library and doing just enough to get it working, but not committing to do any future work. I'm in the lucky position that because PECL is so hard to use (and gate-keepered as to who can use it), that I was able to hold off doing the release of Imagick with PHP 8.0 support until a couple of companies stepped up with a (greatly appreciated) non-trivial amount of sponsorship. What the future holds for open source is unclear to me. And it's not at all obvious that open source isn't a morally wrong thing to do, as to a large extent it seems to rely on individuals subsidising for profit companies. However I don't think that slowing down the improvements in PHP core itself is an appropriate response to companies refusing to pay to support the projects they rely as a business on. I do recommend anyone who has an open source project to: * make sure you have github sponsors or other sponsoring services setup. * ask for payment for work done previously. If you've created a library that companies are dependent on, it's okay to refuse to work on it until there is a decent amount of support for that work done. You don't have to commit to doing new work until the project has a sustainable rate of sponsorship. * compare the amount of money you're getting for a project to the commercial rates for developers, and not to how much cup of coffee is. * Feel free to forward any cash you don't feel justified keeping to other opensource projects particularly upstream dependencies or tools. Or if you don't have enough time to work on that project yourself, feel free to ask for enough money to pay someone else to work on it. Once those done, it's perfectly acceptable to put a project on 'strike' until it's funded adequately and refuse to release new versions to accomodate changes in PHP. I know that saying 'no' to users is draining as they so often try to guilt maintainers into doing work for free. If anyone would like me to help explain to users "your company needs to start sponsoring this project before this project will acknowledge this issue", in any of their projects repos, please ping me on twitter https://twitter.com/MrDanack cheers Dan Ack