Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120643
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <eaaa805e-86b2-ce8c-5a24-c301260d16ac@php.net> <CAH5C8xUrNktmO=t1-357uE0UAZHe0O2zYdAxwE3a0Oo-MK7R=Q@mail.gmail.com>
 <CAH5C8xXjMP+D5szYCZdWqe2pdQTPOMbuFEtJGZeoeTYBcJFOrw@mail.gmail.com>
 <108411AD-DBC4-4436-8190-7569B7A0805F@gmail.com> <CAH5C8xXY3-YjbO6Dq20hRmLUETA3FEpx+rk4+9J3LwO10R6ojA@mail.gmail.com>
 <CAH5C8xW2eXsC5tY5zkZo9TE2QsvvDjdaLzjjZiGKHSJZq6qFJw@mail.gmail.com>
 <D25C28C4-271D-456D-99A5-DA66971FCD00@gmail.com> <CAH5C8xV=NJKV7KdA3v2M_6ZNPMAF6i38aPXqiCkoTYzBSRzY0g@mail.gmail.com>
 <CALKiJKrPP_DLrsrm_5gBOfZ7Exje+RLJdJrRHx4wu894dvr2Hg@mail.gmail.com>
 <CAH5C8xXc8ty7tNgk60JPXq3UZwUigPsPFd8XV=CzxBGT5xXvZw@mail.gmail.com>
 <CAOWwgpmHh9tcuxrNr2pUJy74gMgouVz=B5WkTtMO1a-Qe7mBmA@mail.gmail.com>
 <d63738cf-2711-8d2a-0935-7ecdabc5c9a6@gmail.com> <CAOWwgpkRdKwFOWwnLciPQRxjimaGtr-ATFFCpFgB1JjH18AyQA@mail.gmail.com>
 <cce7b9ee-c418-f19a-81eb-d2a7a5399949@gmail.com> <CAOWwgp=uRyn5kmv+oG=2ikf5bzwgBOR6RqSedt7nkMmeg+3aNw@mail.gmail.com>
In-Reply-To: <CAOWwgp=uRyn5kmv+oG=2ikf5bzwgBOR6RqSedt7nkMmeg+3aNw@mail.gmail.com>
Date: Tue, 20 Jun 2023 11:02:52 +0100
Message-ID: <CALKiJKrOU+PDa1+DUUxJ9yqMvnHn5AsDtZ5cgV3cvVGtzf5Qhg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000e398f105fe8cc109"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000e398f105fe8cc109
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 20 Jun 2023 at 09:22, Nicolas Grekas <nicolas.grekas+php@gmail.com>
wrote:

> > So are you saying we should deprecate the function-based version
> > completely, and not provide any new names at all? I think I would prefe=
r
> > that to the confusing set of aliases the current RFC text proposes.
> >
>
> I was not but I would be fine with this solution also :)
>


Then I don't understand the reasoning of picking a "best" - is the "best"
one the one that keeps the old name, which is unclear but requires no
changes; or is the "best" one the one that gets a clearer name, and
immediately has a non-overloaded signature that everyone can use?



> > 1) Do nothing. I don't see the current situation as being that big a
> > problem.
> >
>
> The problem is the overloaded signature, which Mate explained in the RFC.
>


Sure; I just don't see any of the things mentioned as big enough problems
to justify significant disruption to users.




> THIS would create confusion to me, because ppl would have
> two names to choose from, and many won't take the time to figure out the
> difference.
>


This is where I don't understand what you or Mat=C3=A9 consider to be the
alternative. If we create any function with a new name, then we have two
names for the user to choose between, regardless of whether that's one old
name and one new, or two new names. That's why I'm saying that if we have
two names at all, they should both be chosen with new users in mind, not
fudged based on a combination of current and new naming styles.

Once the deprecation period is over, we should be left with a pair of names
that obviously signals the difference; or, we should be left with only one
function.

Regards,
--=20
Rowan Tommins
[IMSoP]

--000000000000e398f105fe8cc109--