Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114038
MIME-Version: 1.0
References: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com>
 <28be190c-21ea-b796-cec7-b8db21d14eca@gmail.com> <CAF+90c8n_Ny5h8JyF6jKc0i4Rg_=msKEa1Eum6rQJmcV2cGQvw@mail.gmail.com>
 <CAH5C8xWEA7ujHWp4DXUMKrepH8ef3efnT5zJ49RVSE1qqkvhGA@mail.gmail.com>
In-Reply-To: <CAH5C8xWEA7ujHWp4DXUMKrepH8ef3efnT5zJ49RVSE1qqkvhGA@mail.gmail.com>
Date: Mon, 12 Apr 2021 15:33:23 +0200
Message-ID: <CAF+90c8syP8krO8wMeupfyXmPrZX519LtaxmjLpUjSW0-_Sc=A@mail.gmail.com>
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bfb9ef05bfc68f07"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000bfb9ef05bfc68f07
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 12, 2021 at 3:15 PM M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.c=
om> wrote:

> Hi Nikita and Stanislav,
>
> >  > get_class(), get_parent_class() and get_called_class() without
>> argument
>> >
>> > I'm not sure why. I mean if we want to make them return the same as
>> > self::class etc. - up to the point of actually compiling them as such =
-
>> > no problem, but I don't see why they need to be deprecated. And I
>> > vaguely remember seeing get_class() at least a bunch of times in old
>> > code, when ::class didn't even exist. I don't see a good reason why th=
at
>> > code should be broken.
>> >
>>
>> I agree with you on this one. From my perspective, there should be some
>> technical motivation for deprecations, and this one seems to be more abo=
ut
>> coding style -- it removes an old way to write something, which has been
>> subsumed by a different construct in the meantime. I think M=C3=A1t=C3=
=A9 suggested
>> this one, maybe he can provide additional reasoning.
>>
>
> The technical motivation why I suggested this idea is because the optiona=
l
> parameter of get_class() and get_parent_class() doesn't have a correct
> default value
> since https://wiki.php.net/rfc/get_class_disallow_null_parameter. So I
> don't really mind
> the coding style perspective, I'd only like to ensure that default value
> handling is
> right without reverting the relevant RFC. If you think it's too much of a
> BC break for a
> small gain, then I'm ok to remove this item from the list.
>

Just to get a rough idea on how common these are, on the top 2k composer
packages:

$ rg -t php "get_class\(\)" sources/ | wc -l
379
$ rg -t php "get_parent_class\(\)" sources/ | wc -l
174
$ rg -t php "get_called_class\(\)" sources/ | wc -l
218

For get_class() and get_parent_class() a large fraction of uses seem to be
in generated code. get_parent_class() is almost always used to check if a
parent class exists, not get what it actually is. So the replacement for
that would be get_parent_class(self::class) rather than parent:class.
Here's the grep output if you want to take a look:
https://gist.github.com/nikic/12f963fbb4af9d0b2ef885a7417f6016

I don't have a strong opinion regarding the default value issue. It would
be nicer if we did not have functions with argument count dependent
behavior, but I also don't think it's a big deal in this case. These
functions are still rather benign -- they don't perform crazy signature
overloading like pg_query(), where it's impossible to express the signature
in normal PHP code anymore.

Overall I'm unsure the breakage is worthwhile here. Maybe someone else
wants to chime in as well.

Regards,
Nikita

--000000000000bfb9ef05bfc68f07--