Re: [RFC] [Discussion] Deprecate functions with overloaded signatures

On Tue, 2 May 2023 at 13:20, Máté Kocsis <kocsismate90@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]