Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120685
Feedback-ID: id4a9467a:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33
Mime-Version: 1.0
Message-ID: <b19e3af5-6505-40be-b84b-49ba432c46d0@app.fastmail.com>
In-Reply-To: <6B872612-2F31-49E0-949C-CDF6FB2B9BE4@benramsey.com>
References: 
 <CAH5C8xV2ph8GOTDVZjK968+_AKLrrgkoTNDZpK6oE71PXhrOPQ@mail.gmail.com>
 <6B872612-2F31-49E0-949C-CDF6FB2B9BE4@benramsey.com>
Date: Mon, 26 Jun 2023 21:43:01 +0200
To: "Ben Ramsey" <ben@benramsey.com>,
 =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>
Cc: "Levi Morrison" <internals@lists.php.net>
Content-Type: multipart/alternative;
 boundary=5240c3b904b242ff9fb5d5874c55240a
Subject: Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures
From: nikita.ppv@gmail.com ("Nikita Popov")

--5240c3b904b242ff9fb5d5874c55240a
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:
> > On Jun 26, 2023, at 08:36, M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail=
.com> wrote:
> >=20
> > Hi Everyone,
> >=20
> > As previously announced on the list, I have just started the vote ab=
out the
> > "Deprecate functions with overloaded signatures".
> >=20
> > Link to the RFC:
> > https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatu=
res
> > Link to the discussion thread: https://externals.io/message/120146
> >=20
> > The vote is open until 2023-07-10 16:00:00 UTC.
> >=20
> > Regard,
> > M=C3=A1t=C3=A9
>=20
>=20
> Clarifying my =E2=80=9Cno=E2=80=9D votes=E2=80=A6
>=20
> I voted =E2=80=9Cno=E2=80=9D on `array_keys()` because I do not see th=
ese as two different function signatures. To me, the single signature sh=
ould look like this:
>=20
>     function array_keys(array $array, ?mixed $filter_value =3D null, b=
ool $strict =3D false): array {}
>=20
> I voted =E2=80=9Cno=E2=80=9D on `IntlCalendar::set()` because it seems=
 to me that `setDate()` and `setDateTime()` could share the same signatu=
re if `$hour`, `$minute`, and `$second` all default to zero, like this:
>=20
>     public function setDate(int $year, int $month, int $dayOfMonth, in=
t $hour =3D 0, int $minute =3D 0, int $second =3D 0): void {}
>=20
> In the same way, with `IntlGregorianCalendar::__construct()`, `createF=
romDate()` and `createFromDateTime()` could be combined as:
>=20
>     public static function createFromDate(int $year, int $month, int $=
dayOfMonth, int $hour =3D 0, int $minute =3D 0, int $second =3D 0): void=
 {}

So commonality here is that these are all arity overloads.

I think there's three different kinds of overloads in involved in the RF=
C:

1. static/non-static overloads. Support for this was dropped in PHP 8, b=
ut had to be retained internally just for that one usage in FII, so gett=
ing rid of that seems quite high value.

2. type/meaning overloads, where certain parameters change meaning entir=
ely across overloads. These are incompatible with named parameters and r=
esult in very unclear function signatures. They only become intelligible=
 once split into separate signatures, which is not something PHP support=
s. Removing these is also fairly high value.

3. arity overloads, where behavior depends on number of parameters, or c=
ertain parameter counts are forbidden, but the actual meaning of the par=
ameters does not change. Equivalent to a func_num_args() check in userla=
nd code. I think these arity overloads are pretty harmless. The function=
 signature is meaningful and compatible with named arguments.

My overall inclination here is to vote No on all the deprecations that i=
nvolve arity overloads and vote Yes on the remainder.

Possibly I'm missing some kind of complication that the arity overloads =
are causing?

Regards,
Nikita
--5240c3b904b242ff9fb5d5874c55240a--