Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116382
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34
Mime-Version: 1.0
Message-ID: <ff13af3d-dcff-45c6-b47a-3353a16c918a@www.fastmail.com>
In-Reply-To: <ae25a625-20ca-bc9a-d1ee-0f7ac4eba7c7@gmail.com>
References: 
 <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
 <CAF+90c9XwAwbA60NQgnu5btiuE_Y9n8eASnVi8TH65jK3A2C8w@mail.gmail.com>
 <alpine.DEB.2.23.453.2111150948120.4221@singlemalt.home.derickrethans.nl>
 <371ca983-2b07-ae39-3629-49cf7ff8ee64@heigl.org>
 <CAF+90c-om9Qq7YAaf_GdRxKn5e-=8WRVDvy1gC=pA2C8dH=Wqg@mail.gmail.com>
 <497ab532-a39d-389c-8bca-86768650c2f4@heigl.org>
 <ae25a625-20ca-bc9a-d1ee-0f7ac4eba7c7@gmail.com>
Date: Mon, 15 Nov 2021 11:20:40 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Nov 15, 2021, at 10:52 AM, Rowan Tommins wrote:
> On 15/11/2021 16:23, Andreas Heigl wrote:
>> One thing, that can verify the correct working of properties, whether 
>> that is dynamic or static ones, is testing.
>
>
> Can it? I can't actually see how that would work, without also having a 
> way to detect when dynamic properties were accessed, which brings us 
> full circle. Also:
>
>
>> So the mistakes-part would be easy to handle. 
>
> If you are working with a million lines of code going back 20 years, 
> "write tests for everything" is not "easy to handle"; it's a long-term 
> ambition which you chip away at when priorities allow.
>
> "Logging all deprecations and warnings on a production workload", 
> however, *is* easy to handle. Diagnostic messages in logs are the *only* 
> way this behaviour will be spotted in old code.
>
>
>> What I am still missing is the differentiation between "everything is 
>> strict and you have to explicitly opt-in to make it dynamic" and an 
>> "everything is dynamic and you can use a marker to mark this 
>> explicitly an intended behaviour". That would allow users to mark a 
>> class explicitly to use dynamic features even though it would make no 
>> difference code-wise.
>
>
> I'm not sure what you mean by that. Do you mean, create the attribute, 
> but don't actually do anything with it? Would the plan be to deprecate 
> later? Never remove at all?

A possible idea to help make this transition (which I do support) more gradual:

Instead of an "allow" attribute, introduce a boolean flag attribute.  

#[DynamicProperties(true)]
class Beep {}

The attribute marks whether dynamic properties are enabled or disabled via boolean.  If disabled, then they're an error if used.

8.2: Introduce the attribute, with a default of TRUE.  Exactly zero code breaks, but people can start adding the attribute now.  That means people who want to lock-out dynamic properties can do so starting now, and those cases that do need them (or can't easily get away from them) can be flagged far in advance.
8.something: Change the default to FALSE.  Using dynamic properties when false throws a deprecation, not an error.  People have had some number of years to add the attribute either direction if desired.
9.0: Change the deprecation to an error, if the attribute is set false (which by now is the default) and dynamic properties are used.
Sometime in the future: Setting the attribute to true triggers a deprecation.
Sometime in the future: Remove dynamic properties entirely, and the attribute along with it.  People can use __get/__set if they really need.

This still gets us to the same place in the end, but introduces another stage along the way to make the transition more gradual.  We can debate which version the default should flip in, I don't much mind.  That could even wait for 9 if we want to be really really gradual about it.

Meanwhile, IDEs and code templates can start including the attribute set to false by default on any new classes that get written, just like they have done for years with strict types.

Nikita, would that be feasible?  Matthew, Derick, would that be satisfactory?

--Larry Garfield