Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116434
MIME-Version: 1.0
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>
 <62c884b8-813e-43b2-b7bc-db87d4b05f9b@www.fastmail.com>
In-Reply-To: <62c884b8-813e-43b2-b7bc-db87d4b05f9b@www.fastmail.com>
Date: Tue, 16 Nov 2021 19:12:19 -0600
Message-ID: <CAESVnVqDpugdhe8CH-jeoPFg+jDHWnPgBd5TgHZNB49UVfscLg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006e0e4905d0f1bcf6"
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: pollita@php.net (Sara Golemon)

--0000000000006e0e4905d0f1bcf6
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 16, 2021 at 5:55 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> 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.
>
>
Okay sure, but that's an argument about lead time, not about
implementation.  If we agree on targeting 9.0 for this becoming an error
(and I think we do), then the argument that's left is whether users get
notified as early as 8.2, or if they only get notified as of 8.3.
Personally, I want to give users MORE lead time, but having the deprecation
warnings come up sooner, rather than later.  Assuming 9.0 comes out in late
2025 (guesstimate based on the cadence of 7.x), then including the
deprecation with 8.2 (released in late 2022) will give users three years to
attach an attribute where needed.  If we delay the deprecation notice until
8.3 (released in late 2023), then they only have two years.

I know this is the opposite end of lead time than you're talking about (you
want max lead time before a deprecation notice even shows up), and here's
why you're wrong:  Most users don't pay attention to internals.  That extra
year you give them until notices show up will be wasted in ignorance as
they don't know they have any work to do at all.  All you will have done is
robbed them of a year to implement the escape hatch (though let's be
honest, they don't even need ONE year to do it).  The only developers
paying attention to internals@ traffic are the ones who have literally
already added this attribute to their code bases in anticipation of this
change.


> 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.
>
>
Your premise is that, since deprecation warnings will be ignored, we should
increase the verbosity level of the warning, but only for people who
clearly know that a problem exists and can opt in to it?  I'm sorry, but I
don't track the logic of that.

-Sara

--0000000000006e0e4905d0f1bcf6--