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