Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Peter Bowyer]

On Thu, 25 Nov 2021 at 20:58, Dan Ackroyd  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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Dan Ackroyd]

On Fri, 12 Nov 2021 at 19:00, Matthew Weier O'Phinney
 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Craig Francis]

On Tue, 16 Nov 2021 at 22:21, Sara Golemon  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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Nikita Popov]

On Wed, Nov 17, 2021 at 5:35 AM Paul Crovella 
wrote:

> On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov  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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Paul Crovella]

On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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  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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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.

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Larry Garfield]

On Tue, Nov 16, 2021, at 7:18 AM, Lynn wrote:
> On Tue, Nov 16, 2021 at 1:23 PM Pierre Joye  wrote:
>
>> On Tue, Nov 16, 2021 at 4:11 PM Lynn  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Lynn]

On Tue, Nov 16, 2021 at 1:23 PM Pierre Joye  wrote:

> On Tue, Nov 16, 2021 at 4:11 PM Lynn  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.

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

On Tue, Nov 16, 2021 at 4:11 PM Lynn  wrote:
>
>
>
> On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Lynn]

On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye  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 :)

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

Hi,

On Tue, Nov 16, 2021, 4:40 AM Matthew Brown 
wrote:

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov  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

>

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Matthew Brown]

On Mon, 15 Nov 2021 at 17:32, Chase Peeler  wrote:

>
>
> On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown 
> 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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Chase Peeler]

On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown 
wrote:

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov  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
chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Matthew Brown]

On Fri, 12 Nov 2021 at 08:08, Nikita Popov  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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

On Sun, Nov 14, 2021, 11:42 PM Rowan Tommins 
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
>
>

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

Hi Nikita,

On Fri, Nov 12, 2021, 11:34 PM Nikita Popov  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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Claude Pache]

> Le 12 nov. 2021 à 17:24, Ben Ramsey  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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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  
wrote:
On Sat, 13 Nov 2021, 00:14 Christoph M. Becker, > 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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Peter Bowyer]

On Sat, 13 Nov 2021, 00:14 Christoph M. Becker,  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

>

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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  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:
.
 To give one example: ; 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Matthew Weier O'Phinney]

On Fri, Nov 12, 2021, 3:41 PM Larry Garfield  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 

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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  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
mweierophin...@gmail.com
https://mwop.net/
he/him

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Deleu]

On Fri, Nov 12, 2021 at 6:47 PM Chase Peeler  wrote:

> On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield 
> wrote:
>
> > On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote:
> > > On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov 
> > wrote:
> > >
> > >> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey  wrote:
> > >>
> > >>> > On Nov 12, 2021, at 10:10, Derick Rethans  wrote:
> > >>> >
> > >>> > On 12 November 2021 13:07:42 GMT, Nikita Popov <
> nikita@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
> chasepee...@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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Chase Peeler]

On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield 
wrote:

> On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote:
> > On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov 
> wrote:
> >
> >> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey  wrote:
> >>
> >>> > On Nov 12, 2021, at 10:10, Derick Rethans  wrote:
> >>> >
> >>> > On 12 November 2021 13:07:42 GMT, Nikita Popov  >
> >>> 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
chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[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  wrote:
>
>> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey  wrote:
>>
>>> > On Nov 12, 2021, at 10:10, Derick Rethans  wrote:
>>> >
>>> > On 12 November 2021 13:07:42 GMT, Nikita Popov 
>>> 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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Nikita Popov]

On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov  wrote:

> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey  wrote:
>
>> > On Nov 12, 2021, at 10:10, Derick Rethans  wrote:
>> >
>> > On 12 November 2021 13:07:42 GMT, Nikita Popov 
>> 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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Christoph M. Becker]

On 12.11.2021 at 17:24, Ben Ramsey wrote:

>> On Nov 12, 2021, at 10:10, Derick Rethans  wrote:
>>
>> On 12 November 2021 13:07:42 GMT, Nikita Popov  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Nikita Popov]

On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey  wrote:

> > On Nov 12, 2021, at 10:10, Derick Rethans  wrote:
> >
> > On 12 November 2021 13:07:42 GMT, Nikita Popov 
> 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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Ben Ramsey]

> On Nov 12, 2021, at 10:10, Derick Rethans  wrote:
> 
> On 12 November 2021 13:07:42 GMT, Nikita Popov  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



signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Derick Rethans]

On 12 November 2021 13:07:42 GMT, Nikita Popov  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 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php