[RFC] Deprecate dynamic properties View as Markdown

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

--

To unsubscribe, visit: https://www.php.net/unsub.php

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

Hi Juliette,

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