[VOTE] Deprecate dynamic properties

  116325
November 12, 2021 13:07 nikita.ppv@gmail.com (Nikita Popov)
Hi internals,

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

Regards,
Nikita
  116326
November 12, 2021 16:10 derick@php.net (Derick Rethans)
On 12 November 2021 13:07:42 GMT, Nikita Popov 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
  116327
November 12, 2021 16:24 ramsey@php.net (Ben Ramsey)
> On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> wrote: > > On 12 November 2021 13:07:42 GMT, Nikita Popov 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.” Meanwhile, 8.2 should include the AllowDynamicProperties attribute so folks can start preparing. Cheers, Ben
  116328
November 12, 2021 16:34 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey <ramsey@php.net> wrote:

> > On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> wrote: > > > > On 12 November 2021 13:07:42 GMT, Nikita Popov 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
  116330
November 12, 2021 16:56 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov ppv@gmail.com> wrote:

> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey <ramsey@php.net> wrote: > >> > On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> wrote: >> > >> > On 12 November 2021 13:07:42 GMT, Nikita Popov 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
  116331
November 12, 2021 17:43 larry@garfieldtech.com ("Larry Garfield")
On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote:
> On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov ppv@gmail.com> wrote: > >> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey <ramsey@php.net> wrote: >> >>> > On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> wrote: >>> > >>> > On 12 November 2021 13:07:42 GMT, Nikita Popov 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
  116332
November 12, 2021 17:47 chasepeeler@gmail.com (Chase Peeler)
On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote: > > On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov ppv@gmail.com> > wrote: > > > >> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey <ramsey@php.net> wrote: > >> > >>> > On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> wrote: > >>> > > >>> > On 12 November 2021 13:07:42 GMT, Nikita Popov 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > 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
  116333
November 12, 2021 17:53 deleugyn@gmail.com (Deleu)
On Fri, Nov 12, 2021 at 6:47 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield <larry@garfieldtech.com> > wrote: > > > On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote: > > > On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov ppv@gmail.com> > > wrote: > > > > > >> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey <ramsey@php.net> wrote: > > >> > > >>> > On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> 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 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > 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
  116345
November 14, 2021 11:48 pierre.php@gmail.com (Pierre Joye)
Hi Nikita,

On Fri, Nov 12, 2021, 11:34 PM Nikita Popov ppv@gmail.com> wrote:

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
  116346
November 14, 2021 16:42 rowan.collins@gmail.com (Rowan Tommins)
On 14/11/2021 11:48, Pierre Joye 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". 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]
  116353
November 15, 2021 03:16 pierre.php@gmail.com (Pierre Joye)
On Sun, Nov 14, 2021, 11:42 PM Rowan Tommins collins@gmail.com>
wrote:

> On 14/11/2021 11:48, Pierre Joye 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] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  116329
November 12, 2021 16:44 cmbecker69@gmx.de ("Christoph M. Becker")
On 12.11.2021 at 17:24, Ben Ramsey wrote:

>> On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> wrote: >> >> On 12 November 2021 13:07:42 GMT, Nikita Popov 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. > > 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
  116344
November 13, 2021 17:28 claude.pache@gmail.com (Claude Pache)
> 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
  116334
November 12, 2021 18:59 mweierophinney@gmail.com ("Matthew Weier O'Phinney")
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.

On Fri, Nov 12, 2021 at 7:08 AM Nikita Popov 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. > > Regards, > Nikita >
-- Matthew Weier O'Phinney mweierophinney@gmail.com https://mwop.net/ he/him
  116335
November 12, 2021 21:41 larry@garfieldtech.com ("Larry Garfield")
On Fri, Nov 12, 2021, at 12:59 PM, Matthew Weier O'Phinney wrote:
> 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
  116336
November 12, 2021 22:34 mweierophinney@gmail.com ("Matthew Weier O'Phinney")
On Fri, Nov 12, 2021, 3:41 PM Larry Garfield <larry@garfieldtech.com> wrote:

> On Fri, Nov 12, 2021, at 12:59 PM, Matthew Weier O'Phinney wrote: > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  116337
November 13, 2021 00:13 cmbecker69@gmx.de ("Christoph M. Becker")
On 12.11.2021 at 23:34, Matthew Weier O'Phinney wrote:

> On Fri, Nov 12, 2021, 3:41 PM Larry Garfield <larry@garfieldtech.com> wrote: > >> 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
  116338
November 13, 2021 08:26 phpmailinglists@gmail.com (Peter Bowyer)
On Sat, 13 Nov 2021, 00:14 Christoph M. Becker, <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
>
  116340
November 13, 2021 11:25 crocodile2u@gmail.com (Victor Bolshov)
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 > >>
  116516
November 25, 2021 20:58 Danack@basereality.com (Dan Ackroyd)
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: 1. it's going to cause some work for projects that deliberately use this feature. 2. 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
  116527
November 26, 2021 09:56 phpmailinglists@gmail.com (Peter Bowyer)
On Thu, 25 Nov 2021 at 20:58, Dan Ackroyd <Danack@basereality.com> wrote:

> 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: 1. https://externals.io/message/106453
  116531
November 26, 2021 16:15 larry@garfieldtech.com ("Larry Garfield")
On Fri, Nov 26, 2021, at 3:56 AM, Peter Bowyer wrote:

> --- > 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
  116394
November 15, 2021 21:40 matthewmatthew@gmail.com (Matthew Brown)
On Fri, 12 Nov 2021 at 08:08, Nikita Popov 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. > > Regards, > Nikita >
There are two things developers think about when releasing code: 1. does it work for me 2. 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
  116395
November 15, 2021 22:31 chasepeeler@gmail.com (Chase Peeler)
On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov 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. > > > > Regards, > > Nikita > > > > There are two things developers think about when releasing code: > > 1. does it work for me > 2. 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
  116397
November 15, 2021 23:36 matthewmatthew@gmail.com (Matthew Brown)
On Mon, 15 Nov 2021 at 17:32, Chase Peeler <chasepeeler@gmail.com> wrote:

> > > 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
  116400
November 16, 2021 03:52 pierre.php@gmail.com (Pierre Joye)
Hi,

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

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov 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. > > > > 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
>
  116403
November 16, 2021 09:11 kjarli@gmail.com (Lynn)
On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye php@gmail.com> wrote:

> > 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 :)
  116409
November 16, 2021 12:22 pierre.php@gmail.com (Pierre Joye)
On Tue, Nov 16, 2021 at 4:11 PM Lynn <kjarli@gmail.com> wrote:
> > > > On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye php@gmail.com> wrote: >> >> >> 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
  116411
November 16, 2021 13:18 kjarli@gmail.com (Lynn)
On Tue, Nov 16, 2021 at 1:23 PM Pierre Joye php@gmail.com> wrote:

> On Tue, Nov 16, 2021 at 4:11 PM Lynn <kjarli@gmail.com> wrote: > > 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.
  116418
November 16, 2021 16:35 larry@garfieldtech.com ("Larry Garfield")
On Tue, Nov 16, 2021, at 7:18 AM, Lynn wrote:
> On Tue, Nov 16, 2021 at 1:23 PM Pierre Joye php@gmail.com> wrote: > >> On Tue, Nov 16, 2021 at 4:11 PM Lynn <kjarli@gmail.com> wrote: >> > 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
  116428
November 16, 2021 22:20 pollita@php.net (Sara Golemon)
Serious questions for all the folks worried that this is some kind of death
nail for PHP.

1. Do you have code you're responsible for which uses dynamic properties so
broadly that adding this attribute is a burden?
2. 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.
  116432
November 17, 2021 00:29 tobias.nyholm@gmail.com (Tobias Nyholm)
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

> On 16 Nov 2021, at 14:20, Sara Golemon <pollita@php.net> wrote: > > Serious questions for all the folks worried that this is some kind of death > nail for PHP. > > 1. Do you have code you're responsible for which uses dynamic properties so > broadly that adding this attribute is a burden? > 2. 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.
  116485
November 23, 2021 01:38 craig@craigfrancis.co.uk (Craig Francis)
On Tue, 16 Nov 2021 at 22:21, Sara Golemon <pollita@php.net> wrote:

> 1. Do you have code you're responsible for which uses dynamic properties so > broadly that adding this attribute is a burden? > 2. 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
  116435
November 17, 2021 04:35 paul.crovella@gmail.com (Paul Crovella)
On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov 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. > > 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
  116436
November 17, 2021 09:04 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Nov 17, 2021 at 5:35 AM Paul Crovella crovella@gmail.com>
wrote:

> On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov 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. > > > > 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
  116512
November 25, 2021 15:50 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Nov 12, 2021 at 2:07 PM Nikita Popov 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. > > 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
  116525
November 26, 2021 09:06 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Nov 12, 2021 at 2:07 PM Nikita Popov 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. >
The RFC has been accepted with 52 votes in favor and 25 against. Regards, Nikita
  116850
January 9, 2022 13:15 sebastian@php.net (Sebastian Bergmann)
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!
  116851
January 9, 2022 13:54 cmbecker69@gmx.de ("Christoph M. Becker")
On 09.01.2022 at 14:15, Sebastian Bergmann wrote:

> 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