Le mer. 14 juin 2023 à 23:51, Máté Kocsis <kocsismat...@gmail.com> a écrit :

> >
> > 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.

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.


Reply via email to