Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116431
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34
Mime-Version: 1.0
Message-ID: <62c884b8-813e-43b2-b7bc-db87d4b05f9b@www.fastmail.com>
In-Reply-To: 
 <CAESVnVqzJYCjbMgErVFt4bTTO=wppqdFpt7zPaeLYqvDiOuwbQ@mail.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>
 <ff13af3d-dcff-45c6-b47a-3353a16c918a@www.fastmail.com>
 <CAESVnVqzJYCjbMgErVFt4bTTO=wppqdFpt7zPaeLYqvDiOuwbQ@mail.gmail.com>
Date: Tue, 16 Nov 2021 17:55:19 -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 Tue, Nov 16, 2021, at 4:10 PM, Sara Golemon wrote:
> On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield <larry@garfieldtech.com>
> wrote:
>
>> 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.
>>
>
> This is exactly what Nikita is proposing, except that instead of the
> attribute being introduced in PHP 8.2, he's proposing to introduce it
> EARLIER.  Roughly PHP 2 sort of timeframe.
>
> This is because attributes are forward compatible by design and developers
> can already start adding #[AllowDynamicProperties] to their code NOW.  Even
> their code that was written to run cleanly on PHP 5.6 because users are
> terrible at upgrading their servers despite a 2x performance increase.
> </rant>
>
> The point is, we don't need 8.2 to be a soft-launch before deprecation
> because precisely nobody is prevented from adding this attribute
> preemptively.
>
> -Sara

It's not *quite* the same, although your point about preemptive attributes is valid.

1. If we adopt the RFC right now as-is, the market has ~12 months to add the attribute.  If we instead have a default-true flag that changes to default false in the future, it means at minimum 24 months in which to add the attribute to opt-in to dynamic properties.

2. The RFC as-is has no way for developers to opt-in to actively rejecting dynamic properties.  They'll get a deprecation, but... we're shouting from the rooftops that deprecations shouldn't be a big red warning, so if you want a big red warning you can't get that until PHP 9.  With the flag attribute, developers could opt into "please slap me across the face if I use dynamic properties by accident" in ~12 months when 8.2 ships, rather than waiting 36-48 months until the likely PHP 9 release.

So it gives the nitpickers what they want sooner, and gives the old-codies more time to get their ducks in a row.

--Larry Garfield