Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116355
Date: Mon, 15 Nov 2021 09:52:57 +0000 (GMT)
To: PHP internals <internals@lists.php.net>
cc: Nikita Popov <nikita.ppv@gmail.com>
In-Reply-To: <CAF+90c9XwAwbA60NQgnu5btiuE_Y9n8eASnVi8TH65jK3A2C8w@mail.gmail.com>
Message-ID: <alpine.DEB.2.23.453.2111150948120.4221@singlemalt.home.derickrethans.nl>
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com> <CAF+90c9XwAwbA60NQgnu5btiuE_Y9n8eASnVi8TH65jK3A2C8w@mail.gmail.com>
User-Agent: Alpine 2.23 (DEB 453 2020-06-18)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: derick@php.net (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

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug