Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120631
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <648B28D5.1060506@adviesenzo.nl>
 <CAH5C8xV7gbobYEg_xACcnG2za9gNrd8HqvSatsCKBVWJzH2Q2g@mail.gmail.com>
Cc: internals@lists.php.net
Message-ID: <64912128.1@adviesenzo.nl>
Date: Tue, 20 Jun 2023 05:46:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAH5C8xV7gbobYEg_xACcnG2za9gNrd8HqvSatsCKBVWJzH2Q2g@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------050008090106040401060001"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------050008090106040401060001
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 19-6-2023 23:16, Máté Kocsis wrote:
> Hi,
>
> The impact analysis on userland code seems to be missing for some of the
>> proposals, most notably for the proposals which I expect will have the
>> highest impact. I'd like to ask for an impact analysis to be added to
>> each of these:
>> * array_keys()
>> * ReflectionProperty::setValue()
>>
> These are intentionally left out due to different reasons:
>
> * Even though the 1 parameter version of array_keys() is used a lot, its 2+
> parameter signature is much less known.
> Personally, I've never used it. Of course, this doesn't mean no one uses
> it, but I don't think this deprecation will really
> matter in practice, so I didn't care to write a script for this (the rest
> of the deprecations were easy to analyze via regexes).
>
> * ReflectionProperty::setValue() would be a lot of work to analyze since
> it's very difficult to track whether the
> setValue() method is called on a ReflectionProperty instance. Not to
> mention the fact that the deprecation only affects
> function invocations where either a single parameter is provided or static
> properties where the first parameter is not null
> or an object instance. Since the suggested alternative is basically
> available since forever, I think it's OK not to do
> an exhaustive analysis in this case.
>
>
>> For the `get*_class()` deprecation, I wonder if an additional impact
>> analysis is needed for packages which may not have removed usages of
>> `get_class( null )`, which would now be double-impacted (and not caught
>> by the current analysis).
>>
> I'm not sure I can follow you, but get_class(null) is a TypeError since 8.0
> (and have been warning since 7.2). If a package
> didn't feel the need to migrate its get_class() usages then it is likely a
> dead project. And if someone tries to upgrade their
> (proprietary) code from PHP 7.1 to PHP 8.3 directly then they will notice
> the exception first and also - if they followed the upgrading
> notes carelly - will learn the relevant suggestions regarding the
> deprecation. But realistically speaking, these projects will most probably
> be bound by lots of other more severe issues, so I don't think the above is
> a viable upgrade path...
>
> Regards,
> Máté
>
Thanks for the reply Máté.

I understand what you are saying and appreciate it may be difficult to 
get an accurate impact analysis for `ReflectionProperty::setValue()`.

Respectfully though, in my opinion selectively leaving out impact 
analysis without mentioning why they are missing in the RFC, reeks of 
trying to hide information which could influence the vote.
Maybe just mentioning why the impact analysis is missing in these cases 
in the RFC could take that stench away ?

Smile,
Juliette

--------------050008090106040401060001--