Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120575
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>
In-Reply-To: <CAH5C8xV=NJKV7KdA3v2M_6ZNPMAF6i38aPXqiCkoTYzBSRzY0g@mail.gmail.com>
Date: Wed, 14 Jun 2023 15:04:25 +0100
Message-ID: <CALKiJKrPP_DLrsrm_5gBOfZ7Exje+RLJdJrRHx4wu894dvr2Hg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000ae333605fe176eed"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000ae333605fe176eed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 13 Jun 2023 at 15:49, M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.com=
> wrote:

> I understand that communication is much simpler with your suggested
> approach, however, deprecating something which everyone surely uses partl=
y
> undermines the efforts we have made for ensuring as much backward
> compatibility as reasonably possible.
>


Given that you've agreed that neither signature is "primary" or "better",
doesn't that argument apply equally to both signatures? If it's OK to force
anyone using individual callbacks to change their code, why is it not
equally OK to force anyone using an object to change their code?

I do wonder if this change is too disruptive relative to the benefit it
brings, but in that case, we should just leave the whole function as it is.



> In my opinion, the "_object" suffix is superfluous. There would be two
> session_set_handler*() functions: the first one accepts a session handler
> (instance) (session_set_handler()) and the second one accepts session
> handler callbacks (session_set_handler_callbacks()). They are not primary
> or secondary, I just don't like the "_object" suffix, and I couldn't come
> up with a better alternative.
>


I don't think "handler" particularly implies "object". The "handler" passed
to set_error_handler is a function, and your original suggestion for a new
function was "session_set_save_handlers", where "handler" would also mean
"function".

My interpretation of the names is that both versions of the function "set a
session handler", but they differ in what type of handler - one "sets a
session handler using function callbacks", the other "sets a session
handler using an object instance". Thus, the first is
"session_set_handler_functions" or "session_set_handler_callbacks" or so,
and the second is "session_set_handler_object" or
"session_set_handler_instance" or so.

Without any suffix at all, it seems like "set a session handler the normal
way" vs "set a session a special different way"; like how
"array_merge_recursive" is a special version of "array_merge".

Regards,
--=20
Rowan Tommins
[IMSoP]

--000000000000ae333605fe176eed--