Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120639
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>
In-Reply-To: <cce7b9ee-c418-f19a-81eb-d2a7a5399949@gmail.com>
Date: Tue, 20 Jun 2023 10:21:54 +0200
Message-ID: <CAOWwgp=uRyn5kmv+oG=2ikf5bzwgBOR6RqSedt7nkMmeg+3aNw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000b6bbed05fe8b58e2"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000b6bbed05fe8b58e2
Content-Type: text/plain; charset="UTF-8"

> Then, among both options, we need to select the one with the best future
> > proofness, and that's definitely the OOP one to me, because it comes with
> > more guarantees (type checks).
>
>
> So are you saying we should deprecate the function-based version
> completely, and not provide any new names at all? I think I would prefer
> that to the confusing set of aliases the current RFC text proposes.
>

I was not but I would be fine with this solution also :)


> I think I would support any of these options:
>
> 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.


> 2) Deprecate the function-based signature, provide no alternative but to
> switch to the interface-based one. Potentially non-trivial upgrade for
> those affected, but leaves us with a single clear function.
>

Would work for me! The OOP way can be implemented since more than 10 years.


> 3) Create new names for both signatures, treating neither of them as
> more "default" than the other, so that users have a clear choice between
> the two. Deprecate the existing function completely.
>

Deprecating in the same version that provides the alternative would create
a lot of friction (even if in this case, it's possible to polyfill, which
makes this a bit less rough). So to me, this path requires providing an
alias without deprecating the OOP version first, and later on deprecating
the current name. 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.

Mate, WDYT of 2)?

Nicolas

--000000000000b6bbed05fe8b58e2--