Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120228
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>
 <CALKiJKpYJuMo8yF+hNxce_x0tf46HwkTwpqr4aQ63Wq-9M6VAw@mail.gmail.com>
In-Reply-To: <CALKiJKpYJuMo8yF+hNxce_x0tf46HwkTwpqr4aQ63Wq-9M6VAw@mail.gmail.com>
Date: Wed, 10 May 2023 23:28:16 +0200
Message-ID: <CAH5C8xXz07UZZd1Ooj9eXmMjq9QyMnYnLs7jo6TyNDg6VUrhgQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000007cfcb005fb5d8d24"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000007cfcb005fb5d8d24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Rowan,


> 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 har=
d
> as someone else already had". I think the change can be defended from oth=
er
> angles, but wanted to call that out.
>

I admit that my argument was not a good one, but I intended to mean that
most of
the suggested alternatives are not too difficult to implement: since
numerous other proposals
were accepted in the past with a much more difficult upgrade path, I think
this aspect
of my RFC shouldn't be a deal breaker considering the benefits.

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"?


To be honest, I'm not a fan of using the longer names
(session_set_save_handler_functions
and stream_context_set_option_array), especially the latter one looks weird
to me, and it
doesn't go well with stream_context_get_options().

Besides, a most interesting development is that I've just discovered the
stream_context_get_params()
and stream_context_set_params() functions which do nearly the same what the
stream_context_*et_option
functions do: the only difference between them is that the latter functions
wrap the options inside the
"options" key and also has an additional "notification" key.

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:


Thanks for the idea, your explanation made sense to me, so finally, I
removed assert_options() from
my proposal and the deprecation of assert_options() relies on the PHP 8.3
deprecations RFC.

Regards:
M=C3=A1t=C3=A9

--0000000000007cfcb005fb5d8d24--