[VOTE] Deprecate dynamic properties

3 years ago by Derick Rethans — view source

unread

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but because I think the timeline for deprecation and removal is way too fast.

This is IMO not something important enough to cause a fairly large BC break for, and it should wait until the last in the 8.x series before we deprecate it.

cheers
Derick

3 years ago by Ben Ramsey — view source

unread

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but because I think the timeline for deprecation and removal is way too fast.

This is IMO not something important enough to cause a fairly large BC break for, and it should wait until the last in the 8.x series before we deprecate it.

cheers
Derick

I’ve voted no for the same reason.

I like this change, but the deprecation in 8.2 seems too disruptive. I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.” Meanwhile, 8.2 should include the
AllowDynamicProperties attribute so folks can start preparing.

Cheers,
Ben

3 years ago by Nikita Popov — view source

unread

On 12 November 2021 13:07:42 GMT, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will
close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but
because I think the timeline for deprecation and removal is way too fast.

This is IMO not something important enough to cause a fairly large BC
break for, and it should wait until the last in the 8.x series before we
deprecate it.

cheers
Derick

I’ve voted no for the same reason.

I like this change, but the deprecation in 8.2 seems too disruptive. I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.”

FWIW I think we should always deprecate things as soon as possible, to give
people the maximum amount of awareness and time to address the issue before
the actual removal occurs. Most people will not be aware they need to take
action if it's just a note in the manual. For that reason, I find it
generally preferable to deprecate something closer to PHP 8.0 than to 8.4,
which would be directly before a major version with limited time to act.
Now, we don't usually tend to optimize for "time of deprecation" because
that requires planning deprecations many years in advance, but if the
choice existed I'd always go for deprecating early in the major release
cycle, rather than late.

Meanwhile, 8.2 should include the
AllowDynamicProperties attribute so folks can start preparing.

Given how attributes in PHP work, this doesn't make sense to me. You can
already use #[AllowDynamicProperties] in your code right now, without any
special support from PHP. Only static analyzers / IDEs need to know that
they shouldn't complain about it even on versions where it does not
technically exist.

Regards,
Nikita

3 years ago by Nikita Popov — view source

unread

On 12 November 2021 13:07:42 GMT, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will
close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but
because I think the timeline for deprecation and removal is way too fast.

This is IMO not something important enough to cause a fairly large BC
break for, and it should wait until the last in the 8.x series before we
deprecate it.

cheers
Derick

I’ve voted no for the same reason.

I like this change, but the deprecation in 8.2 seems too disruptive. I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.”

FWIW I think we should always deprecate things as soon as possible, to
give people the maximum amount of awareness and time to address the issue
before the actual removal occurs. Most people will not be aware they need
to take action if it's just a note in the manual. For that reason, I find
it generally preferable to deprecate something closer to PHP 8.0 than to
8.4, which would be directly before a major version with limited time to
act. Now, we don't usually tend to optimize for "time of deprecation"
because that requires planning deprecations many years in advance, but if
the choice existed I'd always go for deprecating early in the major release
cycle, rather than late.

Another thing I want to add here is that in this instance, I think that the
deprecation warning is really helpful for updating your code. It tells you
exactly which property on which class is being created dynamically, so you
can quickly go through these and add missing property declarations or
#[AllowDynamicProperties] attributes. Without the deprecation warning in
place, you need a static analyzer to find problematic cases. And of course,
that only works well if you already have a fully typed code base that is
reasonably clean under static analysis. At the same time, this change is
most likely to affect projects where this is not the case. If you are
already using a static analyzer, you probably don't use dynamic properties
anyway, as these things tend to be incompatible.

Regards,
Nikita

3 years ago by Larry Garfield — view source

unread

On 12 November 2021 13:07:42 GMT, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will
close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but
because I think the timeline for deprecation and removal is way too fast.

This is IMO not something important enough to cause a fairly large BC
break for, and it should wait until the last in the 8.x series before we
deprecate it.

cheers
Derick

I’ve voted no for the same reason.

I like this change, but the deprecation in 8.2 seems too disruptive. I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.”

FWIW I think we should always deprecate things as soon as possible, to
give people the maximum amount of awareness and time to address the issue
before the actual removal occurs. Most people will not be aware they need
to take action if it's just a note in the manual. For that reason, I find
it generally preferable to deprecate something closer to PHP 8.0 than to
8.4, which would be directly before a major version with limited time to
act. Now, we don't usually tend to optimize for "time of deprecation"
because that requires planning deprecations many years in advance, but if
the choice existed I'd always go for deprecating early in the major release
cycle, rather than late.

Another thing I want to add here is that in this instance, I think that the
deprecation warning is really helpful for updating your code. It tells you
exactly which property on which class is being created dynamically, so you
can quickly go through these and add missing property declarations or
#[AllowDynamicProperties] attributes. Without the deprecation warning in
place, you need a static analyzer to find problematic cases. And of course,
that only works well if you already have a fully typed code base that is
reasonably clean under static analysis. At the same time, this change is
most likely to affect projects where this is not the case. If you are
already using a static analyzer, you probably don't use dynamic properties
anyway, as these things tend to be incompatible.

Regards,
Nikita

Also a reminder that deprecations are not errors; PHPUnit very recently changed to not complain about deprecations by default. And anyone running with deprecations on in production is doing it wrong and will get bitten whenever the deprecation is enabled.

I have to agree with Nikita here. Give people as much deprecation time as possible; if people are misunderstanding deprecations and abusing them, that's... a different problem that cannot be solved by not issuing deprecations.

--Larry Garfield

3 years ago by Chase Peeler — view source

unread

On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield larry@garfieldtech.com
wrote:

On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov nikita.ppv@gmail.com
wrote:

On 12 November 2021 13:07:42 GMT, Nikita Popov <nikita.ppv@gmail.com

wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will
close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but
because I think the timeline for deprecation and removal is way too
fast.

This is IMO not something important enough to cause a fairly large BC
break for, and it should wait until the last in the 8.x series before
we
deprecate it.

cheers
Derick

I’ve voted no for the same reason.

I like this change, but the deprecation in 8.2 seems too disruptive.
I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.”

FWIW I think we should always deprecate things as soon as possible, to
give people the maximum amount of awareness and time to address the
issue
before the actual removal occurs. Most people will not be aware they
need
to take action if it's just a note in the manual. For that reason, I
find
it generally preferable to deprecate something closer to PHP 8.0 than to
8.4, which would be directly before a major version with limited time to
act. Now, we don't usually tend to optimize for "time of deprecation"
because that requires planning deprecations many years in advance, but
if
the choice existed I'd always go for deprecating early in the major
release
cycle, rather than late.

Another thing I want to add here is that in this instance, I think that
the
deprecation warning is really helpful for updating your code. It tells
you
exactly which property on which class is being created dynamically, so
you
can quickly go through these and add missing property declarations or
#[AllowDynamicProperties] attributes. Without the deprecation warning in
place, you need a static analyzer to find problematic cases. And of
course,
that only works well if you already have a fully typed code base that is
reasonably clean under static analysis. At the same time, this change is
most likely to affect projects where this is not the case. If you are
already using a static analyzer, you probably don't use dynamic
properties
anyway, as these things tend to be incompatible.

Regards,
Nikita

Also a reminder that deprecations are not errors; PHPUnit very recently
changed to not complain about deprecations by default. And anyone running
with deprecations on in production is doing it wrong and will get bitten
whenever the deprecation is enabled.

I have to agree with Nikita here. Give people as much deprecation time as
possible; if people are misunderstanding deprecations and abusing them,
that's... a different problem that cannot be solved by not issuing
deprecations.

--Larry Garfield

--

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

I don't think this should be deprecated or removed at all. However, I agree
that if it is going to be removed, the more time/versions that exists
between deprecation and removal, the better.

Chase Peeler
chasepeeler@gmail.com

3 years ago by Deleu — view source

unread

On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield larry@garfieldtech.com
wrote:

On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov nikita.ppv@gmail.com
wrote:

On 12 November 2021 13:07:42 GMT, Nikita Popov <
nikita.ppv@gmail.com

wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting
will
close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but
because I think the timeline for deprecation and removal is way too
fast.

This is IMO not something important enough to cause a fairly large
BC
break for, and it should wait until the last in the 8.x series before
we
deprecate it.

cheers
Derick

I’ve voted no for the same reason.

I like this change, but the deprecation in 8.2 seems too disruptive.
I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.”

FWIW I think we should always deprecate things as soon as possible, to
give people the maximum amount of awareness and time to address the
issue
before the actual removal occurs. Most people will not be aware they
need
to take action if it's just a note in the manual. For that reason, I
find
it generally preferable to deprecate something closer to PHP 8.0 than
to
8.4, which would be directly before a major version with limited time
to
act. Now, we don't usually tend to optimize for "time of deprecation"
because that requires planning deprecations many years in advance, but
if
the choice existed I'd always go for deprecating early in the major
release
cycle, rather than late.

Another thing I want to add here is that in this instance, I think that
the
deprecation warning is really helpful for updating your code. It tells
you
exactly which property on which class is being created dynamically, so
you
can quickly go through these and add missing property declarations or
#[AllowDynamicProperties] attributes. Without the deprecation warning
in
place, you need a static analyzer to find problematic cases. And of
course,
that only works well if you already have a fully typed code base that
is
reasonably clean under static analysis. At the same time, this change
is
most likely to affect projects where this is not the case. If you are
already using a static analyzer, you probably don't use dynamic
properties
anyway, as these things tend to be incompatible.

Regards,
Nikita

Also a reminder that deprecations are not errors; PHPUnit very recently
changed to not complain about deprecations by default. And anyone
running
with deprecations on in production is doing it wrong and will get bitten
whenever the deprecation is enabled.

I have to agree with Nikita here. Give people as much deprecation time
as
possible; if people are misunderstanding deprecations and abusing them,
that's... a different problem that cannot be solved by not issuing
deprecations.

--Larry Garfield

--

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

I don't think this should be deprecated or removed at all. However, I agree
that if it is going to be removed, the more time/versions that exists
between deprecation and removal, the better.

Chase Peeler
chasepeeler@gmail.com

I agree with previous replies and would even go as further to say that it
is better to try and avoid deprecation on the last version of a PHP Series.
I like this deprecation, but I also think it's a pretty big deprecation to
happen only 1 year before it's actual removal. Deprecating it now means
people will have at least 3 years to adjust to it. Recently Laravel also
made the same changes that PHPUnit did to stop converting deprecations into
fatal errors so that users can still use deprecated code if they need more
time to accommodate.

--
Marco Aurélio Deleu

3 years ago by Pierre Joye — view source

unread

Hi Nikita,

FWIW I think we should always deprecate things as soon as possible, to give

people the maximum amount of awareness and time to address the issue before
the actual removal occurs.

I voted no however I agree on this part, with a slight different view on
how it may be done.

Meanwhile, 8.2 should include the

AllowDynamicProperties attribute so folks can start preparing.

Given how attributes in PHP work, this doesn't make sense to me. You can
already use #[AllowDynamicProperties] in your code right now, without any
special support from PHP. Only static analyzers / IDEs need to know that
they shouldn't complain about it even on versions where it does not
technically exist.

I agree with other that it should be allowed by default.

Also I do see it as a kind of strict mode addition and the depreciation as
well could be strict mode only.

It could make things too complicated, so only off by default would be an
acceptable compromise to me.

best
Pierre

3 years ago by Rowan Tommins — view source

unread

Also I do see it as a kind of strict mode addition and the depreciation as
well could be strict mode only.

A quick reminder that PHP has no "strict mode". It has a "strict_types"
declaration, which is probably misnamed, and should be something like
"scalar_types=error" vs "scalar_types=coerce".

Suggestions to add a more general "two modes for the whole language"
approach have generally gone down in flames.

Suggestions to add other declarations tend to run into discussions of
namespace-scoped declares / project configuration / etc

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Pierre Joye — view source

unread

On Sun, Nov 14, 2021, 11:42 PM Rowan Tommins rowan.collins@gmail.com
wrote:

Also I do see it as a kind of strict mode addition and the depreciation
as
well could be strict mode only.

A quick reminder that PHP has no "strict mode". It has a "strict_types"
declaration, which is probably misnamed, and should be something like
"scalar_types=error" vs "scalar_types=coerce".

yes, wrong word.

--

Rowan Tommins
[IMSoP]

--

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

3 years ago by Christoph M. Becker — view source

unread

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

I've voted no on this one. Not because I don't like the idea, but because I think the timeline for deprecation and removal is way too fast.

This is IMO not something important enough to cause a fairly large BC break for, and it should wait until the last in the 8.x series before we deprecate it.

I’ve voted no for the same reason.

I like this change, but the deprecation in 8.2 seems too disruptive. I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.” Meanwhile, 8.2 should include the
AllowDynamicProperties attribute so folks can start preparing.

Didn't we do this for ext/mysql? Had that the desired effect? I don't
think so. Unfortunately, too many devs don't read the docs, and why
would they, if they now how stuff works.

--
Christoph M. Becker

3 years ago by Claude Pache — view source

unread

Le 12 nov. 2021 à 17:24, Ben Ramsey ramsey@php.net a écrit :

I like this change, but the deprecation in 8.2 seems too disruptive. I’d
rather promote our intent to deprecate this with a statement in the
manual that says something like, “This feature will be deprecated in
PHP 8.3 and removed in 9.0.” Meanwhile, 8.2 should include the
AllowDynamicProperties attribute so folks can start preparing.

Kindly recalling that the intended meaning of deprecation warnings is duly documented in the manual? I have read the manual when I designed my error handler many year ago; as a consequence, this deprecation warning will not at all be disruptive for me.

I strongly doubt that a mere statement of intention in the manual is of much utility, given that many people apparently don’t read the manual when they design their error handlers... We should rather more heavily promote the true meaning of “deprecation”.

—Claude

3 years ago by Matthew Weier O'Phinney — view source

unread

I recognize it's a bit late to be commenting, now that voting has
started... but this feels like a solution for which we already have
workable solutions, and which will instead lead to a lot of
misunderstanding and breakage in the user ecosystem.

Our IDEs, coding standards, and static analysis tools can already flag
these things for us, helping us catch them early. Hell, unit testing will
find these for us, when a test fails due to a value not being set in a
property that we expected.

Making this fundamental change to the language means, however, that a lot
of things that we were previously able to do that "just worked" now raise a
deprecation notice, and, later, a compilation error... unless we make a
change to our already working, fully functional code.

I think the Locked Classes approach made far more sense here, because it
didn't require changes to working code. By making the behavior opt-in,
developers get to choose if that's what they want for their classes,
instead of having a backwards breaking change thrust on them.

(Perhaps an even better solution would be a declaration, like we have for
strict_types, which we could do per file.)

Or maybe I'm missing something else: was there something at the engine
level that was driving this, a significant performance gain we get from
changing the behavior? Because if there was, there was no discussion of it.
In fact, the only discussion of "why" in the RFC is "In modern code, this
is rarely done intentionally". Why is that justification for changing the
behavior? Can you quantify how much code would be affected by this change?
and how much would benefit?

Yes, I know that code I write would benefit from it, and personally I'd
love to have a way to opt-in to something more strict - but I think a
switch like this is going to make upgrading to version 9 difficult if not
impossible for a huge number of PHP users.

Sweeping changes like this need data behind them. If there's such data for
this RFC, it's not present in the proposal, and as such, I cannot
understand what drives it.

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

Regards,
Nikita

--
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

3 years ago by Larry Garfield — view source

unread

I recognize it's a bit late to be commenting, now that voting has
started... but this feels like a solution for which we already have
workable solutions, and which will instead lead to a lot of
misunderstanding and breakage in the user ecosystem.

Our IDEs, coding standards, and static analysis tools can already flag
these things for us, helping us catch them early. Hell, unit testing will
find these for us, when a test fails due to a value not being set in a
property that we expected.

Making this fundamental change to the language means, however, that a lot
of things that we were previously able to do that "just worked" now raise a
deprecation notice, and, later, a compilation error... unless we make a
change to our already working, fully functional code.

I think the Locked Classes approach made far more sense here, because it
didn't require changes to working code. By making the behavior opt-in,
developers get to choose if that's what they want for their classes,
instead of having a backwards breaking change thrust on them.

(Perhaps an even better solution would be a declaration, like we have for
strict_types, which we could do per file.)

Or maybe I'm missing something else: was there something at the engine
level that was driving this, a significant performance gain we get from
changing the behavior? Because if there was, there was no discussion of it.
In fact, the only discussion of "why" in the RFC is "In modern code, this
is rarely done intentionally". Why is that justification for changing the
behavior? Can you quantify how much code would be affected by this change?
and how much would benefit?

Yes, I know that code I write would benefit from it, and personally I'd
love to have a way to opt-in to something more strict - but I think a
switch like this is going to make upgrading to version 9 difficult if not
impossible for a huge number of PHP users.

Sweeping changes like this need data behind them. If there's such data for
this RFC, it's not present in the proposal, and as such, I cannot
understand what drives it.

The original version of the RFC would have (as of v9) allowed for the removal of some fugly code in property handling, resulting in engine improvements and some minor performance benefits. That was because it pushed the opt-in mechanism to "only if you extend stdclass", and stdclass would effectively have a trait with stock __get/__set implementations to handle dynamic property behavior. (It wasn't quite that, but effectively that's what it would do.) So that was the original impetus.

The current version doesn't actually remove the behavior yet, so it wouldn't allow for that optimization. That does, I agree, weaken its argument, but as the RFC notes makes it easier in the future to figure out how widespread dynamic properties actually are in code today. Right now... we simply don't know. It's possible the impact here will be almost nil, or it could break anything written before 2010. (I'd guess it's closer to the former than the latter, but no one knows for certain.) Just grepping for the attribute in the future would give us a better picture of how common it is.

To those that are arguing that the timeline is too aggressive, I would turn the question around: What timeline would be acceptable? "Well behaved" code hasn't used dynamic properties outside of a few very edge bits in a very, very long time, so transitioning to those being the exception and not the default is, IMO, reasonable. What would be a more comfortable timeline if not what is proposed here?

(Bearing in mind the previous statements that treating deprecations as though they were warnings, even in production, is not Internals problem but a problem of people who have their servers misconfigured.)

--Larry Garfield

3 years ago by Matthew Weier O'Phinney — view source

unread

I recognize it's a bit late to be commenting, now that voting has
started... but this feels like a solution for which we already have
workable solutions, and which will instead lead to a lot of
misunderstanding and breakage in the user ecosystem.

Our IDEs, coding standards, and static analysis tools can already flag
these things for us, helping us catch them early. Hell, unit testing will
find these for us, when a test fails due to a value not being set in a
property that we expected.

Making this fundamental change to the language means, however, that a lot
of things that we were previously able to do that "just worked" now
raise a
deprecation notice, and, later, a compilation error... unless we make a
change to our already working, fully functional code.

I think the Locked Classes approach made far more sense here, because it
didn't require changes to working code. By making the behavior opt-in,
developers get to choose if that's what they want for their classes,
instead of having a backwards breaking change thrust on them.

(Perhaps an even better solution would be a declaration, like we have for
strict_types, which we could do per file.)

Or maybe I'm missing something else: was there something at the engine
level that was driving this, a significant performance gain we get from
changing the behavior? Because if there was, there was no discussion of
it.
In fact, the only discussion of "why" in the RFC is "In modern code, this
is rarely done intentionally". Why is that justification for changing the
behavior? Can you quantify how much code would be affected by this
change?
and how much would benefit?

Yes, I know that code I write would benefit from it, and personally I'd
love to have a way to opt-in to something more strict - but I think a
switch like this is going to make upgrading to version 9 difficult if not
impossible for a huge number of PHP users.

Sweeping changes like this need data behind them. If there's such data
for
this RFC, it's not present in the proposal, and as such, I cannot
understand what drives it.

The original version of the RFC would have (as of v9) allowed for the
removal of some fugly code in property handling, resulting in engine
improvements and some minor performance benefits. That was because it
pushed the opt-in mechanism to "only if you extend stdclass", and stdclass
would effectively have a trait with stock __get/__set implementations to
handle dynamic property behavior. (It wasn't quite that, but effectively
that's what it would do.) So that was the original impetus.

None of that information was in the RFC. That sort of thing really needs to
be included, as it helps a ton in justifying changes of this nature. As I
noted, on reading it, the only rationale made is a quick mention that they
lead to programming errors, and even then, there's no detail really if
how.

The current version doesn't actually remove the behavior yet, so it
wouldn't allow for that optimization. That does, I agree, weaken its
argument, but as the RFC notes makes it easier in the future to figure out
how widespread dynamic properties actually are in code today. Right now...
we simply don't know. It's possible the impact here will be almost nil, or
it could break anything written before 2010. (I'd guess it's closer to the
former than the latter, but no one knows for certain.) Just grepping for
the attribute in the future would give us a better picture of how common it
is.

That's the thing: it's guesswork. About a fundamental way the object model
works. While most library code may not make use of it, I can think of a
number of ways I've seen it used or used the feature myself without even
trying too hard:

In unit tests, to create quick spies to pass into closures.
In API wrappers, to represent payloads of specific types. (This is
particularly interesting, as it allows for these wrappers to be forward
compatible with additions to the API payload).
As internal DTO messages, particularly when prototyping. I get the
benefits of a typed object without needing to fully define its properties.

And that's just off the top of my head.

To those that are arguing that the timeline is too aggressive, I would
turn the question around: What timeline would be acceptable? "Well
behaved" code hasn't used dynamic properties outside of a few very edge
bits in a very, very long time, so transitioning to those being the
exception and not the default is, IMO, reasonable. What would be a more
comfortable timeline if not what is proposed here?

(Bearing in mind the previous statements that treating deprecations as
though they were warnings, even in production, is not Internals problem but
a problem of people who have their servers misconfigured.)

I'm bringing this up again: because deprecations are reported by changing a
flag to error reporting, and because the default dev configuration enables
that flag, and it's included as part of E_ALL, the reality is that many
users see the deprecations.

When those errors point to libraries they consume, they report them.

Yes, library maintainers can have policies to consider errors due to
deprecations as invalid. But they still need to evaluate and review those
issues, which takes time and effort. And ignoring the issue often means it
gets reported repeatedly.

The other option is to deal with the deprecation. But this then means
yearly churn, as the project creates new deprecations with each minor
version.

Listen, I'm happy about a lot of the changes to the language as a user. But
as a library maintainer:

Changes to fundamental, decades long behavior has huge knock-on effects
for us, and causes a lot of busy work.
Yearly deprecations trigger an onslought of issues and patches that do
nothing for the average user, and detract from other work, such as bug
fixes and feature additions.

I'd like for a discussion on how we can allow the language to develop
without requiring yearly churn and burden on the surrounding ecosystem. And
just waving your hands and saying deprecations aren't errors is not an
answer - if it makes its way to an error log or is reported inline in a
page or in CLI output, it's an error.

--Larry Garfield

--

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

3 years ago by Christoph M. Becker — view source

unread

The original version of the RFC would have (as of v9) allowed for the
removal of some fugly code in property handling, resulting in engine
improvements and some minor performance benefits. That was because it
pushed the opt-in mechanism to "only if you extend stdclass", and stdclass
would effectively have a trait with stock __get/__set implementations to
handle dynamic property behavior. (It wasn't quite that, but effectively
that's what it would do.) So that was the original impetus.

None of that information was in the RFC. That sort of thing really needs to
be included, as it helps a ton in justifying changes of this nature. As I
noted, on reading it, the only rationale made is a quick mention that they
lead to programming errors, and even then, there's no detail really if
how.

At some point, the RFC explained some of the internal implications:
https://wiki.php.net/rfc/deprecate_dynamic_properties?rev=1629900759#internal_impact.
To give one example: https://3v4l.org/f8OZj; no that's not a memory
leak, but rather the effects of materializing the properties HashTable.

However, since the attribute solution, which already was a compromise to
mitigate the BC break wouldn't make it possible to drop
zend_object.properties and friends, this reasoning was removed. I still
hope that we can get rid of this ugly stuff eventually. Obviously, that
requires to educate people and to push code bases "softly". Offering an
opt-out of dynamic properties or some switch to disable the deprecation
would not help in that regard.

That "leading to programming errors" is about userland code. Mistyping
the property name might not even be noticed during development/QA, but
may cause serious issues in production. Of course, a static analyzer
would report this issue, but there is code where you'd have a hard time
to get PHPStan level 0 or Psalm level 8 working (and baseline wouldn't
catch existing issues). Oh, and well, we're actually talking about code
which is not statically analyzed (or only at a very low level) anyway,
don't we?

I'd like for a discussion on how we can allow the language to develop
without requiring yearly churn and burden on the surrounding ecosystem. And
just waving your hands and saying deprecations aren't errors is not an
answer - if it makes its way to an error log or is reported inline in a
page or in CLI output, it's an error.

I'd argue that it is not. There are different levels of errors, and you
should likely treat them as such. An error or exception is more severe
than a warning, a warning is more severe than a notice, and a
deprecation is yet different again. You can ignore the latter, if you
don't care about the next PHP major yet; you can actually exclude them
from any kind of error reporting, until you care enough about them to
resolve them. Even libraries could add a "suspended" ("won't fix
now") label to respective bug reports (and re-open when the time has
come).

Anyhow, I'm fully aware that PHP is pushing for years now. As far as I
know, COBOL did not.

--
Christoph M. Becker

3 years ago by Peter Bowyer — view source

unread

Offering an
opt-out of dynamic properties or some switch to disable the deprecation
would not help in that regard.

Given this is a big change to the way PHP has behaved for decades I did
wonder why the RFC didn't propose an opt-out of dynamic properties rather
than opt-in, preserving the long-term language behaviour. So thanks for
covering that.

I think you and the PHP internals community will be surprised by how widely
used dynamic properties are. I read through a handful of WordPress plugins
we have installed and found a few. And in my own where I'm using a named
class instead of an array.

I work with modern framework based code most of the time and I find it easy
to forget what is out there as quintessential or traditional PHP code.

Whether we have #[AllowDynamicProperties] or #[DenyDynamicProperties] one
set of PHP users is going to be doing a find & replace across their
codebase.

From a DX perspective I'd rather have #[DenyDynamicProperties] as it's like
declaring strict_mode and opt-in.

Either way are the planned engine changes feasible, as the feature of
dynamic properties stays in the language but toggled off/on per class?

Peter

3 years ago by Victor Bolshov — view source

unread

The way I see it, it might look similar to strict_types opt-in, but
only on the surface. The amount of changes needed to make legacy code
compliant with strict_types directive, would be tremendous, also there
would be no simple one-size-fits-all solution like the
#[AllowDynamicProperties]. In that sense, these two are hardly
comparable.

I agree with the change (not that I have a voting karma, just
watching). I also agree with Andreas Heigl saying that at certain point
changes like this probably should happen, and regardless of exactly
when, it is going to cause debate and complaints, but we as community
should probably prefer having a long deprecation cycle for smoother
transition, which is why the suggested timeline is IMO good (that is,
if the community represented by core devs will vote for this RFC).

Opt-in strategy - #[DenyDynamicProperties] - for a change like this
would effectively do nothing. I personally would be against this change
at all then.

Many thanks to the PHP team from userland, also for letting anyone
voice their thoughts and concerns on important matters!

Regards,
Victor Bolshov,
Software developer

On za, nov 13, 2021 at 08:26, Peter Bowyer phpmailinglists@gmail.com
wrote:

On Sat, 13 Nov 2021, 00:14 Christoph M. Becker, <cmbecker69@gmx.de
mailto:cmbecker69@gmx.de> wrote:

Offering an
opt-out of dynamic properties or some switch to disable the
deprecation
would not help in that regard.

Given this is a big change to the way PHP has behaved for decades I
did
wonder why the RFC didn't propose an opt-out of dynamic properties
rather
than opt-in, preserving the long-term language behaviour. So thanks
for
covering that.

I think you and the PHP internals community will be surprised by how
widely
used dynamic properties are. I read through a handful of WordPress
plugins
we have installed and found a few. And in my own where I'm using a
named
class instead of an array.

I work with modern framework based code most of the time and I find
it easy
to forget what is out there as quintessential or traditional PHP code.

Whether we have #[AllowDynamicProperties] or #[DenyDynamicProperties]
one
set of PHP users is going to be doing a find & replace across their
codebase.

From a DX perspective I'd rather have #[DenyDynamicProperties] as
it's like
declaring strict_mode and opt-in.

Either way are the planned engine changes feasible, as the feature of
dynamic properties stays in the language but toggled off/on per class?

Peter

2 years ago by Dan Ackroyd — view source

unread

On Fri, 12 Nov 2021 at 19:00, Matthew Weier O'Phinney
mweierophinney@gmail.com wrote:

Our IDEs, coding standards, and static analysis tools can already flag
these things for us, helping us catch them early. Hell, unit testing will
find these for us, when a test fails due to a value not being set in a
property that we expected.

New users don't have these tools. And a lot of 'experienced'
developers don't have those tools either. A disconcerting number of
developers don't even use source control.

Although exactly which users a language should be designed to cater
for, I don't think an answer of "those who have used it long enough to
setup static analysis tools" is a great one.

But even when people have static analysis tools setup, they are slow to run.

Andreas Heigl wrote:

So while the static analysis is one possibility, the other
one is writing appropriate tests.
.....
So the mistakes-part would be easy to handle.

This is not my experience.

My experience is the same as Matthew Brown wrote:

I have heard newcomers express literal
surprise when discovering this for the first time, and not in a delighted
way.

People encounter the 'feature' of PHP not warning or erroring on
dynamically creating a property by accident most of the time.

They make a typo in their code and wonder why their code isn't working
as expected.

Even though I use an IDE, and have pretty comprehensive static
analysis and tests, this feature keeps biting me often enough that I
created a trait to stop it
(https://github.com/Danack/Params/blob/main/lib/Params/SafeAccess.php)
which I normally copy and paste into each project.

Matthew Weier O'Phinney wrote:

Making this fundamental change to the language means, however, that a lot
of things that we were previously able to do that "just worked" now raise a
deprecation notice, and, later, a compilation error... unless we make a
change to our already working, fully functional code.

This is the trade-off that all RFCs that have BC breaks have:

it's going to cause some work for projects that deliberately use
this feature.
it's going to save time/improve the developer experience for people
in the future

If PHP was a dead language that fewer people are starting to learn,
and few new projects are started using it, then option 1 is probably
the side to prioritise. But I'm hoping that PHP isn't a dead language,
and that the future benefit from not having to spend so long debugging
their code is greater than a small amount of BC break.

For the people who are currently voting 'no', I'd ask are you really
sure that the amount of work adding "#[AllowDynamicProperties]" to the
classes you want to keep having dynamic properties is really that much
time compared to the time that would be saved by having PHP itself
give an error when a user accidentally creates a dynamic property?

cheers
Dan
Ack

2 years ago by Peter Bowyer — view source

unread

For the people who are currently voting 'no', I'd ask are you really
sure that the amount of work adding "#[AllowDynamicProperties]" to the
classes you want to keep having dynamic properties is really that much
time compared to the time that would be saved by having PHP itself
give an error when a user accidentally creates a dynamic property?

No, I don't. I see the vote as a "boiling frog" moment and a protest vote
in reaction to other changes which have had a bigger impact on
backwards-compatibility.

I get the impression a lot of comments on this mailing list are from people
who know other languages, would like to work with another language, and
since they (have to?) use PHP would like PHP to be another language.

I find that fascinating. And I'd be well up for having a round-table
discussion and recording a podcast on it.

PHP fills a big niche. it's not the niche that most people on this list
seem to want it to fill, but it does. And the results people accomplish
with PHP - not in spite of PHP, but because of PHP - are impressive.

There are unresolved discussions that have been going on since at least
2019 [1] about direction and what PHP should become. With the formation of
the PHP Foundation I hope these can be revisited.

Peter

References:

https://externals.io/message/106453

2 years ago by Larry Garfield — view source

unread

I get the impression a lot of comments on this mailing list are from people
who know other languages, would like to work with another language, and
since they (have to?) use PHP would like PHP to be another language.

I find that fascinating. And I'd be well up for having a round-table
discussion and recording a podcast on it.

People have been making that complaint about other people since at least 2005 or so. "You're turning PHP into Java, stop it." "You're turning PHP into Ruby, stop it." "Just go use Rust instead if you want that feature and leave us alone."

PHP evolves by stealing ideas from every language it can, without shame, and is a far, far better language today because of it. Please, stop with the "you just want to be like language X" complaint. It's over-used, inaccurate, and just plain ignorant as an argument.

There are ample reasons to argue against any particular feature, but "it makes PHP too much like language X" is a particularly bad one that everyone needs to stop using, forever.

--Larry Garfield

3 years ago by Matthew Brown — view source

unread

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

Regards,
Nikita

There are two things developers think about when releasing code:

does it work for me
does it work for everyone else

With its support for runtime type hints and other similar checks, PHP does
a reasonably good job of aligning those two — what works for me generally
works for everyone else, too.

Using dynamic properties is one of the areas where "works for me" and
"works for everyone else" can diverge. Some people use static analysis to
keep track of those divergences, but if PHP can warn people they're doing
a probably-dumb thing, I think it should.

I encourage people to vote "yes" on this, if you want PHP to be better at
preventing people from shooting themselves in the foot. I know there are
valid uses for this, but it's nevertheless a surprising feature, and not
one that delights many PHP developers. Making it attribute-only from 9.0
onwards seems incredibly sensible.

Best wishes,

Matt

3 years ago by Chase Peeler — view source

unread

On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown matthewmatthew@gmail.com
wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

Regards,
Nikita

There are two things developers think about when releasing code:

does it work for me

does it work for everyone else

With its support for runtime type hints and other similar checks, PHP does
a reasonably good job of aligning those two — what works for me generally
works for everyone else, too.

Using dynamic properties is one of the areas where "works for me" and
"works for everyone else" can diverge. Some people use static analysis to
keep track of those divergences, but if PHP can warn people they're doing
a probably-dumb thing, I think it should.

Warning someone is very different than not allowing it

I encourage people to vote "yes" on this, if you want PHP to be better at
preventing people from shooting themselves in the foot.

What if I want a language where people can shoot themselves in the foot
because the flexibility it offers is what makes it great

I know there are
valid uses for this, but it's nevertheless a surprising feature, and not
one that delights many PHP developers.

Why is this surprising? It's been available since classes were introduced
to PHP.

Making it attribute-only from 9.0
onwards seems incredibly sensible.

Best wishes,

Matt

--
Chase Peeler
chasepeeler@gmail.com

3 years ago by Matthew Brown — view source

unread

On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown matthewmatthew@gmail.com
wrote:

I encourage people to vote "yes" on this, if you want PHP to be better at
preventing people from shooting themselves in the foot.

What if I want a language where people can shoot themselves in the foot
because the flexibility it offers is what makes it great

I don't think this particular feature makes PHP great, and I don't think
the active PHP community thinks that either.

I know there are

valid uses for this, but it's nevertheless a surprising feature, and not
one that delights many PHP developers.

Why is this surprising? It's been available since classes were introduced
to PHP.

Not everyone who uses PHP has been using it since time immemorial. Some of
us came from compiled languages where this behaviour is expressly
prohibited, while others are used to interpreted languages that also
prohibit this behaviour.

This is what I mean by surprising: I have heard newcomers express literal
surprise when discovering this for the first time, and not in a delighted
way.

Best wishes,

Matt

3 years ago by Pierre Joye — view source

unread

Hi,

On Tue, Nov 16, 2021, 4:40 AM Matthew Brown matthewmatthew@gmail.com
wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

Regards,
Nikita

I encourage people to vote "yes" on this, if you want PHP to be better

My vote will change to yes as soon as the change is an opt-in instead of an
opt-out for the 8.x lifetime.

best,
Pierre

3 years ago by Lynn — view source

unread

My vote will change to yes as soon as the change is an opt-in instead of an
opt-out for the 8.x lifetime.

What is the point of this change if it's an opt-in? Projects that are still
relying on dynamic properties today and "have no time" to fix them now,
won't have time in 3 years either. Please let us have nice things today
instead of years from now :)

3 years ago by Pierre Joye — view source

unread

My vote will change to yes as soon as the change is an opt-in instead of an
opt-out for the 8.x lifetime.

What is the point of this change if it's an opt-in? Projects that are still relying on dynamic properties today and "have no time" to fix them now, won't have time in 3 years either. Please let us have nice things today instead of years from now :)

If it is an opt-in (like Larry proposes f.e.), you will have them
today as well.

Best,

Pierre

@pierrejoye | http://www.libgd.org

3 years ago by Lynn — view source

unread

What is the point of this change if it's an opt-in? Projects that are
still relying on dynamic properties today and "have no time" to fix them
now, won't have time in 3 years either. Please let us have nice things
today instead of years from now :)

If it is an opt-in (like Larry proposes f.e.), you will have them
today as well.

Just to be clear, are you talking about opting in to having the
deprecation, thus adding it to every single class in my code base, and
every new class added in the future? Or are you talking about opting in to
enabling dynamic properties? Because the first makes it pointless to have
while the latter makes this a great RFC.

3 years ago by Larry Garfield — view source

unread

What is the point of this change if it's an opt-in? Projects that are
still relying on dynamic properties today and "have no time" to fix them
now, won't have time in 3 years either. Please let us have nice things
today instead of years from now :)

If it is an opt-in (like Larry proposes f.e.), you will have them
today as well.

Just to be clear, are you talking about opting in to having the
deprecation, thus adding it to every single class in my code base, and
every new class added in the future? Or are you talking about opting in to
enabling dynamic properties? Because the first makes it pointless to have
while the latter makes this a great RFC.

I believe Pierre is referring to my suggestion here: https://externals.io/message/115800#116382

--Larry Garfield

3 years ago by Sara Golemon — view source

unread

Serious questions for all the folks worried that this is some kind of death
nail for PHP.

Do you have code you're responsible for which uses dynamic properties so
broadly that adding this attribute is a burden?
Do you know of real code in widespread use which uses dynamic properties
so broadly that adding this attribute is a burden?

All I see being bandied about are hypotheticals. So here's my answers: In
my entire career (which granted, is only about half actually written IN
php) I can point to exactly one class* which makes use of dynamic props and
it would take me a hot minute to add the attribute and commit it to the
repo (note: This code base is running on 5.x, so it doesn't need it, but it
can handle the attribute all the same). I don't consider that hot minute
to be problematic.

For those wondering what's the point: Making the engine better is the
point. We won't see the payoff in 8.2, or even 9.0, but by 10.0 we should
be able to be in a better place and have a better engine out of it.

-Sara

Not counting uses of stdClass which is going to implicitly have this
attribute.

3 years ago by Tobias Nyholm — view source

unread

Thank you Sara!
I could not agree more with you. I think this answers to most tweets and messages that I’ve seen the past few weeks.

// Tobias

Serious questions for all the folks worried that this is some kind of death
nail for PHP.

Do you have code you're responsible for which uses dynamic properties so
broadly that adding this attribute is a burden?

Do you know of real code in widespread use which uses dynamic properties
so broadly that adding this attribute is a burden?

All I see being bandied about are hypotheticals. So here's my answers: In
my entire career (which granted, is only about half actually written IN
php) I can point to exactly one class* which makes use of dynamic props and
it would take me a hot minute to add the attribute and commit it to the
repo (note: This code base is running on 5.x, so it doesn't need it, but it
can handle the attribute all the same). I don't consider that hot minute
to be problematic.

For those wondering what's the point: Making the engine better is the
point. We won't see the payoff in 8.2, or even 9.0, but by 10.0 we should
be able to be in a better place and have a better engine out of it.

-Sara

Not counting uses of stdClass which is going to implicitly have this
attribute.

3 years ago by Craig Francis — view source

unread

Do you have code you're responsible for which uses dynamic properties so
broadly that adding this attribute is a burden?

Do you know of real code in widespread use which uses dynamic properties
so broadly that adding this attribute is a burden?

All I see being bandied about are hypotheticals.

That's fair, and tbh mine has been the hypothetical legacy code... reading
all the discussion, I think I've been convinced it's worth the change,
especially as this is a deprecation a few versions before anything actually
breaks.

I think my original negative opinion was more of a "oh, not more stuff to
change", especially while I know of a few people now fixing all of the
issues that "passing null to non-nullable arguments of internal functions"
is causing; with trim, strlen, strpos, etc...
https://externals.io/message/116076

And even more off-topic... well done everyone for on PHP Foundation, and
thank you Nikita for everything you have done (you really have accomplished
a lot).

Craig

3 years ago by Paul Crovella — view source

unread

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

Regards,
Nikita

In the Motivation section when talking about static analysis the RFC
makes the claim:

The #[AllowDynamicProperties] attribute proposed in this RFC makes the cases where dynamic properties are used intentionally explicit.

however this really isn't true as the attribute is on the class rather
than the use. Static analysis will still have no idea whether any
dynamic property assignment is indeed a bug or intentional. The
information added is only whether the author of the class has deemed
it okay for dynamic properties to be used on it, not by it. The class
author and the dynamic property user might not be the same person or
have any relation. The class being intentionally used with dynamic
properties is not necessarily in the user's control. Similarly the
class being unintentionally used with dynamic properties may not be
either.

This user/used mismatch is repeated in the RFC, for example:

Classes marked with #[AllowDynamicProperties] as well as their children can continue using dynamic properties without deprecation or removal.

These classes cannot then use dynamic properties, they can have
dynamic properties used on them.

The inaccurate prevention claim is repeated as well:

#[AllowDynamicProperties] requires making classes that rely on dynamic properties explicit and prevents accidental use of dynamic properties

It may help prevent some, but others can skate through on happenstance.

Cheers,
Paul

3 years ago by Nikita Popov — view source

unread

On Wed, Nov 17, 2021 at 5:35 AM Paul Crovella paul.crovella@gmail.com
wrote:

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

Regards,
Nikita

In the Motivation section when talking about static analysis the RFC
makes the claim:

The #[AllowDynamicProperties] attribute proposed in this RFC makes the
cases where dynamic properties are used intentionally explicit.

however this really isn't true as the attribute is on the class rather
than the use. Static analysis will still have no idea whether any
dynamic property assignment is indeed a bug or intentional. The
information added is only whether the author of the class has deemed
it okay for dynamic properties to be used on it, not by it. The class
author and the dynamic property user might not be the same person or
have any relation. The class being intentionally used with dynamic
properties is not necessarily in the user's control. Similarly the
class being unintentionally used with dynamic properties may not be
either.

There is an assumption in the design, that certain classes are designed to
be used with dynamic properties, and all dynamic properties are acceptable
in that case. This is basically classes that could be using __get/__set,
but instead use dynamic properties for reasons of simplicity, performance
or migration ease. If the class only works with a fixed set of properties
then those should be declared instead, and if it has more complex
constraints, then __get/__set can be used to implement arbitrary rules.
(Setting dynamic properties on classes you do not own and that do not
opt-in is explicitly unsupported under this model, with the recommendation
to use WeakMaps for non-intrusive value association instead.)

Regards,
Nikita

2 years ago by Nikita Popov — view source

unread

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

Regards,
Nikita

As a reminder, voting on this RFC closes tomorrow. I usually don't specify
an exact time, but as the margin is so narrow: I plan to close the vote at
9am UTC.

Regards,
Nikita

2 years ago by Nikita Popov — view source

unread

Hi internals,

I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.

The RFC has been accepted with 52 votes in favor and 25 against.

Regards,
Nikita

2 years ago by Sebastian Bergmann — view source

unread

Am 26.11.2021 um 10:06 schrieb Nikita Popov:

The RFC has been accepted with 52 votes in favor and 25 against.

Has this been merged yet? Thanks!

2 years ago by Christoph M. Becker — view source

unread

Am 26.11.2021 um 10:06 schrieb Nikita Popov:

The RFC has been accepted with 52 votes in favor and 25 against.

Has this been merged yet? Thanks!

Yes, it has been merged on Nov 26th, 2021[1]. FWIW, it's already
available on ev4l.org[2].

[1]
https://github.com/php/php-src/commit/902d64390e49f8bf970588cf53cd8e00630c68bb
[2] https://3v4l.org/JpuGX/rfc

--
Christoph M. Becker

[VOTE] Deprecate dynamic properties

I don't think this should be deprecated or removed at all. However, I agree that if it is going to be removed, the more time/versions that exists between deprecation and removal, the better.

I don't think this should be deprecated or removed at all. However, I agree that if it is going to be removed, the more time/versions that exists between deprecation and removal, the better.

I find that fascinating. And I'd be well up for having a round-table discussion and recording a podcast on it.

I find that fascinating. And I'd be well up for having a round-table discussion and recording a podcast on it.

Best,

I don't think this should be deprecated or removed at all. However, I agree
that if it is going to be removed, the more time/versions that exists
between deprecation and removal, the better.

I don't think this should be deprecated or removed at all. However, I agree
that if it is going to be removed, the more time/versions that exists
between deprecation and removal, the better.

I find that fascinating. And I'd be well up for having a round-table
discussion and recording a podcast on it.

I find that fascinating. And I'd be well up for having a round-table
discussion and recording a podcast on it.