Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117332
Message-ID: <d985b744-b37c-e4d2-3994-322f71d23a13@demon-angel.eu>
Date: Mon, 14 Mar 2022 23:47:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.2
Reply-To: mark@demon-angel.eu
To: internals@lists.php.net
References: <CAPyj-LDVVfrSx1B3DpW+VjOe78twZVbPsGRv+k96MJ=1A3vCAw@mail.gmail.com>
 <20220312031138.5e0669a4@platypus>
 <A0E06DE1-3F3A-4E1A-B2E7-BBB2B4E35E26@gmail.com>
 <20220312123015.3713538b@platypus>
 <492ECA79-EC68-4BEB-AD67-B26A1D68D399@gmail.com>
 <CAPyj-LBk+hwQ3KreV-yi7k9nXqZEd8S86j12qSp3tUeKNy8wOA@mail.gmail.com>
In-Reply-To: <CAPyj-LBk+hwQ3KreV-yi7k9nXqZEd8S86j12qSp3tUeKNy8wOA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string
 interpolation
From: mark@demon-angel.eu (Mark Baker)

On 12/03/2022 15:23, Ilija Tovilo wrote:
> You're absolutely right. I will attempt to gather some numbers. For
> option 3, I also think "not widely used" is just plain wrong. As for
> option 4, I'm fairly confident it only exists by accident 95% of the
> time.

Like Andreas, this is my biggest concern with the proposal: the lack of 
actual figures for how many libraries will be affected b the change. 
We've seen a lot of deprecations over the last year, and they always 
create some degree of pain for library/toolchain maintainers. While 
typically dismissed as "it's just a deprecation notice", and being 
accused of creating a "storm in a tea cup" whenever we raise questions, 
library maintainers are the ones who have to deal with the additional 
work when end users raise issues against their repos becase of all the 
notices they're nw seeing in their logs; who already have a lot of work 
preparing for each new release; who are expected to have fully 
eliminated any deprecations from their repos (or their dependencies) on 
or before the GA release date. How much extra work and/or stress is it 
going to give those who maintain the PHP ecosystem?

 From the preparation work for the 8.0 release, there has barely been 
breathing space over the last two years; dealing with null arguments 
passed to internal functions, and other (not always docmented) changes, 
those libraries/tools take a lot of work to maintain. And with so many 
deprecations going into this release, I would like to see some risk 
assessment undertaken on the affect that each deprecation RFC will have, 
with some real figures for the number of repositories that require work 
to prepare them for the release.


-- 
Mark Baker

  _________
|.  \     \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|

  I LOVE PHP