On Tue, 13 Jun 2023 at 15:49, Máté Kocsis <kocsismat...@gmail.com> wrote:

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


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?

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


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

My interpretation of the names is that both versions of the function "set a
session handler", but they differ in what type of handler - one "sets a
session handler using function callbacks", the other "sets a session
handler using an object instance". Thus, the first is
"session_set_handler_functions" or "session_set_handler_callbacks" or so,
and the second is "session_set_handler_object" or
"session_set_handler_instance" or so.

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

Regards,
-- 
Rowan Tommins
[IMSoP]

Reply via email to