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