> > In my mind, the only reason to change anything about this function is that > we can't properly overload a function based on its argument types. There's > nothing particularly "primary" or "better" about either of the two > signatures, it's just hard to document and use named parameters while > they're both part of one function. >
Yes, that's the case exactly. > My suggestion was very explicitly that everyone using sessions should have > to change their code, to a name that explicitly mentions the parameter type > in its name (because that's the difference between the two). As I said, I > think it's much simpler to communicate "this function is deprecated, choose > the appropriate from these two names", rather than "this function is > deprecated in one format, but not the other, and if you are using the > deprecated format, you can use this instead". > I understand that communication is much simpler with your suggested approach, however, deprecating something which everyone surely uses partly undermines the efforts we have made for ensuring as much backward compatibility as reasonably possible. That's why I'm not in favor of officially deprecating the object oriented version of session_set_save_handler() just yet. I think soft deprecating it for now results in a smoother upgrade path by letting people optionally use its alias first (session_set_handler()), and then we can start nagging them later on. Otherwise, I would question why we had to have such a long discussion focusing mainly on the BC aspects of the proposal. I also understand that polyfilling session_set_save_handler() would also be easy to do, but the migration is even easier if we leave the 2-parameter version alone for a while. Both the "_object" suffix (or some equivalent) and deprecating the original > regardless of signature are inherent in my suggestion. You seem to have > interpreted it as something else, and I'm not entirely sure what you're > actually proposing - how does an alias fit in to something that's about > splitting a function into two? > In my opinion, the "_object" suffix is superfluous. There would be two session_set_handler*() functions: the first one accepts a session handler (instance) (session_set_handler()) and the second one accepts session handler callbacks (session_set_handler_callbacks()). They are not primary or secondary, I just don't like the "_object" suffix, and I couldn't come up with a better alternative. Regards, Máté
