Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120623
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> <CAH5C8xXc8ty7tNgk60JPXq3UZwUigPsPFd8XV=CzxBGT5xXvZw@mail.gmail.com>
In-Reply-To: <CAH5C8xXc8ty7tNgk60JPXq3UZwUigPsPFd8XV=CzxBGT5xXvZw@mail.gmail.com>
Date: Mon, 19 Jun 2023 22:17:40 +0200
Message-ID: <CAOWwgpmHh9tcuxrNr2pUJy74gMgouVz=B5WkTtMO1a-Qe7mBmA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a8828905fe813ad1"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000a8828905fe813ad1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mer. 14 juin 2023 =C3=A0 23:51, M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmai=
l.com> a =C3=A9crit :

> >
> > 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 th=
e
> 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. Al=
l
> in all, I think neither not doing
> anything, nor deprecating the whole function is a good choice. But at lea=
st
> I definitely want the question
> to be settled with putting this to vote.
>
> I don't think "handler" particularly implies "object". The "handler" pass=
ed
> > to set_error_handler is a function, and your original suggestion for a
> new
> > function was "session_set_save_handlers", where "handler" would also me=
an
> > "function".
> >
>
> Without any suffix at all, it seems like "set a session handler the norma=
l
> > 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 b=
e
> session_set_handler() and session_set_handlers() now. That was the starti=
ng
> 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 correc=
t
> name indeed, but I don't think
> that we always have to choose the most correct and the entirely descripti=
ve
> 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 tha=
t
> 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.
>


I think we must account for a bit of history/legacy on the topic.
I think session_set_save_handler(SessionHandlerInterface) is the best BC/FC
path we can provide.
And I don't think we should alias this function to a new name because that
would require users to make a choice, and will lead to confusion, because
in this case, the choice is purely cosmetic, but people will still have to
get it.

Nicolas

--000000000000a8828905fe813ad1--