Re: Fwd: [PHP-DEV] [RFC] [Discussion] Depr ecate functions with overloaded signatures

On 10 June 2023 08:31:24 BST, "Máté Kocsis" <kocsismate90@gmail.com> wrote: >Hmm, that's also a very good idea, and I support this. However, I'm >hesitant to deprecate the 2 parameter version of session_set_save_handler() >just yet, >since doing so would mean that everyone using sessions has to use a new >function... Instead, I opted for aliasing it to the new >session_set_handler() function (I'm not fond >of the "_object" postfix, because I regard it unnecessary as it operates on >SessionHandlerInterface instances). And we could maybe deprecate >session_set_save_handler() >altogether in a few years. Hm, I think we're not quite on the same page here. 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. 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". 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? Regards, -- Rowan Tommins [IMSoP]