Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120181
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <ffa8138a-f1b6-3926-bc2f-558ffca344b0@gmail.com> <CAH5C8xXhCkZt7bBs7YcjMBRYM5ggu7W47huCCbVwb2-q_zFnBA@mail.gmail.com>
In-Reply-To: <CAH5C8xXhCkZt7bBs7YcjMBRYM5ggu7W47huCCbVwb2-q_zFnBA@mail.gmail.com>
Date: Tue, 2 May 2023 14:07:21 +0100
Message-ID: <CALKiJKpYJuMo8yF+hNxce_x0tf46HwkTwpqr4aQ63Wq-9M6VAw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000060f32605fab59f68"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000060f32605fab59f68
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2 May 2023 at 13:20, M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.com>=
 wrote:

> Yes, but changing session_set_save_handler() to session_set_save_handlers=
()
> should be a reasonably small effort, isn't it? I understand that it's
> going to affect
> lots of codebases, however other PHP 8.x deprecations are much more
> difficult
> to fix than this one would be.
>


Oh, did that proposal change, or did I just misread it?

Maybe because the function names are so similar? In general, I hate
variable and function names that differ only by an "s", it's far too easy
to misread or mistype them. Maybe "session_set_save_handler_functions"?

For the same reason, I much prefer Kamil's suggestion of "
stream_context_set_option_array" over " stream_context_set_options".


As an aside, I don't think "other deprecations are already more difficult"
is a good argument - it's like saying "yes, I punched him, but not as hard
as someone else already had". I think the change can be defended from other
angles, but wanted to call that out.




> Yes, I agree that the assert_options() name is at least weird but I
> wouldn't like to
> include changes into this RFC which are not strictly related to overloade=
d
> signatures. Just like in case of implode(), the 1-parameter version of
> assert_options()
> could be added to the PHP 8.3/8.4 deprecations RFC though.
>


It *is* strictly related, though: the current function has two purposes:
get an option, and set an option; the RFC proposes to split that into two
functions, and there are three ways we can do that:

1) Keep the current name for get, come up with a new name for set
2) Come up with a new name for get, keep the current name for set
3) Come up with new names for both get and set

I then looked further, and suggested:

4) Deprecate the existing function, but do not create any new functions;
instead, recommend ini_get for get, and ini_set for set

All four options are direct remedies to the overloaded signature, and I
think due to the current unclear naming, options 3 and 4 are superior to
options 1 and 2. Do you have a specific reason to prefer option 1?


Regards,
--=20
Rowan Tommins
[IMSoP]

--00000000000060f32605fab59f68--