On Tue, 2 May 2023 at 13:20, Máté Kocsis <kocsismat...@gmail.com> wrote:

> Yes, but changing session_set_save_handler() to session_set_save_handlers()
> should be a reasonably small effort, isn't it? I understand that it's
> going to affect
> lots of codebases, however other PHP 8.x deprecations are much more
> difficult
> to fix than this one would be.
>


Oh, did that proposal change, or did I just misread it?

Maybe because the function names are so similar? In general, I hate
variable and function names that differ only by an "s", it's far too easy
to misread or mistype them. Maybe "session_set_save_handler_functions"?

For the same reason, I much prefer Kamil's suggestion of "
stream_context_set_option_array" over " stream_context_set_options".


As an aside, I don't think "other deprecations are already more difficult"
is a good argument - it's like saying "yes, I punched him, but not as hard
as someone else already had". I think the change can be defended from other
angles, but wanted to call that out.




> Yes, I agree that the assert_options() name is at least weird but I
> wouldn't like to
> include changes into this RFC which are not strictly related to overloaded
> signatures. Just like in case of implode(), the 1-parameter version of
> assert_options()
> could be added to the PHP 8.3/8.4 deprecations RFC though.
>


It *is* strictly related, though: the current function has two purposes:
get an option, and set an option; the RFC proposes to split that into two
functions, and there are three ways we can do that:

1) Keep the current name for get, come up with a new name for set
2) Come up with a new name for get, keep the current name for set
3) Come up with new names for both get and set

I then looked further, and suggested:

4) Deprecate the existing function, but do not create any new functions;
instead, recommend ini_get for get, and ini_set for set

All four options are direct remedies to the overloaded signature, and I
think due to the current unclear naming, options 3 and 4 are superior to
options 1 and 2. Do you have a specific reason to prefer option 1?


Regards,
-- 
Rowan Tommins
[IMSoP]

Reply via email to