Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120627
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <648B28D5.1060506@adviesenzo.nl>
In-Reply-To: <648B28D5.1060506@adviesenzo.nl>
Date: Mon, 19 Jun 2023 23:16:00 +0200
Message-ID: <CAH5C8xV7gbobYEg_xACcnG2za9gNrd8HqvSatsCKBVWJzH2Q2g@mail.gmail.com>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000047353105fe820b07"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--00000000000047353105fe820b07
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=A1t=C3=A9

--00000000000047353105fe820b07--