Hi Rowan and Larry,
> Isn't that exactly what a deprecation period is for? > Yes, sure, but I wrote my arguments with the "Short deprecation period" in mind so that the removal of these functions causes the least pain. > If we want to give people longer, just leave the functionality deprecated > for longer before removing it. If we want to phase that in gradually, start > with a documentation-only deprecation, and add the deprecation notice > later. > If the plan is to keep the current function name, we can't get any of the > (very small) benefits of removing the extra signature until the final > removal anyway. > I don't completely understand this sentence, but my current plan is to go with the original function name as this causes the least impact and at the same time makes the scope of the RFC smaller. I'm tired of the debates (even if they were useful), and I don't want to add any tangentially related things in the RFC anymore. Anyway, adding an alias (session_set_handler()) and/or deprecating the original function name later is trivial, if someone wants to pursue this. > I'd propose a doc-only deprecation now (with session_set_handler() added > for the object version), an E_DEPRECATED in 9.0, and full removal in 10.0. Assuming the expected > release schedule, that gives people ~2 years before they see even an E_DEPRECATED, and 6-7 > years before they are forced to change. That should be ample time for anyone that still needs > to make the switch. I want to keep the original voting choices (the short and long path). Then votes can decide how much notice period they want to give. Since I don't insist on changing the function name anymore, the impact of this change is a lower, as only people using the callback signature would be affected. The fortunate thing is that session handling is used less in library code so at least open source maintainers rarely have to deal with the deprecation. And proprietary code maintainers can mostly ignore or suppress it for a while. Regards, Máté
