Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120578
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>
In-Reply-To: <CALKiJKrPP_DLrsrm_5gBOfZ7Exje+RLJdJrRHx4wu894dvr2Hg@mail.gmail.com>
Date: Wed, 14 Jun 2023 23:51:12 +0200
Message-ID: <CAH5C8xXc8ty7tNgk60JPXq3UZwUigPsPFd8XV=CzxBGT5xXvZw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000fc10f705fe1df395"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000fc10f705fe1df395
Content-Type: text/plain; charset="UTF-8"

>
> 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?
>

As far as I remember, my reasoning was two-fold:
- naming: passing *multiple* callbacks to a function name in singular
(session_set_save_handler())
is definitely not ideal
- a decision had to be made and I thought that keeping the OO approach in
place had less BC impact,
especially because previously I got feedback from Nicolas that they used
this version.


> 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, phasing out session_set_save_handler() completely would be
worth the effort if this
was the only option to fix the overridden signature. However, it's not the
case, since strictly speaking,
only one of the two signatures has to be removed in order to achieve the
desired goal of the RFC.
The whole discussion about also deprecating the other one started only
because of improving naming:
it is also a nice thing to pursue but fails the cost-benefit analysis. All
in all, I think neither not doing
anything, nor deprecating the whole function is a good choice. But at least
I definitely want the question
to be settled with putting this to vote.

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".
>

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".
>

I think my reasoning is easier to understand if we go back to my original
suggestion:
session_set_save_handler() and session_set_save_handlers(), which would be
session_set_handler() and session_set_handlers() now. That was the starting
point,
but you didn't like that they only differ by an "s". That's why I swapped
the "s" with "callbacks".

According to your deduction, session_set_handler() is not the most correct
name indeed, but I don't think
that we always have to choose the most correct and the entirely descriptive
one. After all, neither the
parameters of session_set_handler() are called "$open_callback",
"$close_callback" etc., they are just
"$open", "$close" etc. and I guess they are still clear enough, given that
their type is declared which
completes the missing context.

Similarly, we all would know that the session_set_handler() function
expects an object of
SessionHandlerInterface type, while its sibling,
session_set_handler_callbacks()  expects some
callbacks. Yes, having the _object suffix is the most pedantic name, but
personally, I don't really like it
because I find it ugly (and I was pretty much content with
session_set_handlers()). I'm curious about
the point of view of other people though, because if it turns out that
people generally also favor some
other name then I'm ok with a compromise.

--000000000000fc10f705fe1df395--