HI Nicolas and Rowan, Mate, WDYT of 2)?
Your sentence about better typing rang a bell with me: I think that's the best argument for removing the signature accepting callables. But before coming to a conclusion, let me answer Rowan's question first: This is where I don't understand what you or Maté consider to be the > alternative. If we create any function with a new name, then we have two > names for the user to choose between, regardless of whether that's one old > name and one new, or two new names. That's why I'm saying that if we have > two names at all, they should both be chosen with new users in mind, not > fudged based on a combination of current and new naming styles. > > Once the deprecation period is over, we should be left with a pair of names > that obviously signals the difference; or, we should be left with only one > function. > Of course, the best situation would be to have only the new function name with a single signature. Personally, I also prefer the OO style, but this doesn't really matter now. However, the sad truth is that we have a very widespread function with a slightly incorrect name supporting 2 signatures for more than a decade... On top of that, while most of the other deprecations in the RFC either affect rare functionality, or are suppressable via a simple polyfill or some automation/search+replace, only supporting the OO style signature of session_set_save_handler() would mean that people would have to wrap the callbacks in a class. This is not automatable, and requires some possibly non-trivial manual work. This means that we have to change anything really carefully here. With all these in mind, I'd say that the strategic goal should be to have a single signature + the new function name only. Reaching this state would affect every single proprietary codebase in some way or another, so I don't think it's feasible or fair with users to try it in one single step. So in order to reduce the damage, my plan is the following: * Let's keep one of the two signatures which are compatible with older PHP versions so that at least a fraction of all users (maybe 50-70%?) are not impacted at all. That's why session_set_save_handler() should not be removed just yet. Since the OO version seems more future-proof based on Nicolas' great argument (it accepts an interface, while callbacks don't have a formal signature), we should keep this form. * People who use the signature to be deprecated should not be forced to do non-trivial changes. So introducing a new function for them will keep their code run with a minimal effort (search + replace), while we managed to eliminate the overloaded signature. At the same time, we try to educate them (mostly in the manual) that the best way forward is to migrate their code to use session_set_handler(). There's no deprecation just yet, and everyone can do it voluntarily at their own pace. * In order to finally achieve the strategic goal, we deprecate the old function along with session_set_handler_callbacks() as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z, whatever. This process may sound complicated, but in my opinion, this is the least disruptive upgrade path for achieving the goal I outlined above. Sometimes going full ninja mode is possible, but I'd prefer being careful in this very case, especially because I guess some people do not consider the motivation of the RFC particularly important, so I would like if their cost-benefit analysis would stay positive (I don't only mean voters but end users as well, since their perception also matters when they are fixing the incompatibilities of their code). Máté
