Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120638
Message-ID: <cce7b9ee-c418-f19a-81eb-d2a7a5399949@gmail.com>
Date: Tue, 20 Jun 2023 09:09:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Content-Language: en-GB
To: internals@lists.php.net
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>
In-Reply-To: <CAOWwgpkRdKwFOWwnLciPQRxjimaGtr-ATFFCpFgB1JjH18AyQA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: rowan.collins@gmail.com (Rowan Tommins)

On 20/06/2023 07:26, Nicolas Grekas wrote:
> 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 think I would support any of these options:

1) Do nothing. I don't see the current situation as being that big a 
problem.
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.
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.

All the other suggestions seem likely to create a lot of confusion, and 
not actually leave us much better off in the long term.


Regards,

-- 
Rowan Tommins
[IMSoP]