Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116391
Message-ID: <ed6ad8a8-6cb4-ec38-8979-dee1e6987260@telia.com>
Date: Mon, 15 Nov 2021 21:39:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.1
Content-Language: en-GB
To: Derick Rethans <derick@php.net>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
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>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
In-Reply-To: <alpine.DEB.2.23.453.2111150948120.4221@singlemalt.home.derickrethans.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2021-11-15 kl. 10:52, skrev Derick Rethans:
> Dear Internals,
> 
> On Wed, 10 Nov 2021, Nikita Popov wrote:
> 
>> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>>
>>> This RFC takes the more direct route of deprecating this
>>> functionality entirely. I expect that this will have relatively
>>> little impact on modern code (e.g. in Symfony I could fix the vast
>>> majority of deprecation warnings with a three-line diff), but may
>>> have a big impact on legacy code that doesn't declare properties at
>>> all.
>>>
>>
>> I plan to open voting on this RFC soon. Most of the feedback was
>> positive, apart from the initial choice of opt-int mechanism, and that
>> part should be addressed by the switch to the
>> #[AllowDynamicProperties] attribute.
> 
> The voting is now open, but I think one thing was not taken into account
> here, the many small changes that push work to maintainers of Open
> Source library and CI related tools.
> 
> In the last few years, the release cadence of PHP has increased, which
> is great for new features. It however has not been helpful to introduce
> many small deprecations and BC breaks in every single release.
> 
> This invariably is making maintainers of Open Source anxious, and
> frustrated as so much work is need to keep things up to date. I know
> they are *deprecations*, and applications can turn these off, but that's
> not the case for maintainers of libraries.
> 
> Before we introduce many more of this into PHP 8.2, I think it would be
> wise to figure out a way how to:
> 
> - improve the langauge with new features
> - keep maintenance cost for open source library and CI tools much lower
> - come up with a set of guidelines for when it is necessary to introduce
>    BC breaks and deprecations.
> 
> I am all for improving the language and making it more feature rich, but
> we have not spend enough time considering the impacts to the full
> ecosystem.
> 
> I have therefore voted "no" on this RFC, and I hope you will too.
> 
> cheers,
> Derick
> 
Hi,

Maybe the RM's should have a mandate to keep track on deprecations for
a specific release and be able to say: "Sorry the shop are closed for
further deprecations in this release".

What do you think?

One could count the deprecations in the 8.x track and have a straw poll
on it and/or ask what key deprecations do we see further for the 8.x?

Is even the "Dynamic properties" one, one of the last ones?

r//Björn L