Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120561
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <eaaa805e-86b2-ce8c-5a24-c301260d16ac@php.net> <CAH5C8xUrNktmO=t1-357uE0UAZHe0O2zYdAxwE3a0Oo-MK7R=Q@mail.gmail.com>
 <CAH5C8xXjMP+D5szYCZdWqe2pdQTPOMbuFEtJGZeoeTYBcJFOrw@mail.gmail.com>
 <108411AD-DBC4-4436-8190-7569B7A0805F@gmail.com> <CAH5C8xXY3-YjbO6Dq20hRmLUETA3FEpx+rk4+9J3LwO10R6ojA@mail.gmail.com>
 <CAH5C8xW2eXsC5tY5zkZo9TE2QsvvDjdaLzjjZiGKHSJZq6qFJw@mail.gmail.com> <D25C28C4-271D-456D-99A5-DA66971FCD00@gmail.com>
In-Reply-To: <D25C28C4-271D-456D-99A5-DA66971FCD00@gmail.com>
Date: Tue, 13 Jun 2023 16:49:09 +0200
Message-ID: <CAH5C8xV=NJKV7KdA3v2M_6ZNPMAF6i38aPXqiCkoTYzBSRzY0g@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c62c5c05fe03f0ae"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000c62c5c05fe03f0ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> In my mind, the only reason to change anything about this function is tha=
t
> 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.
>

Yes, that's the case exactly.


> My suggestion was very explicitly that everyone using sessions should hav=
e
> to change their code, to a name that explicitly mentions the parameter ty=
pe
> 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, choo=
se
> 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".
>

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. That's why I'm not in favor of
officially deprecating the object oriented version of
session_set_save_handler() just yet. I think soft deprecating it for now
results in a smoother upgrade path by letting people optionally use its
alias first (session_set_handler()), and then we can start nagging them
later on. Otherwise, I would question why we had to have such a long
discussion focusing mainly on the BC aspects of the proposal. I also
understand that polyfilling session_set_save_handler() would also be easy
to do, but the migration is even easier if we leave the 2-parameter version
alone for a while.

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?
>

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.

Regards,
M=C3=A1t=C3=A9

--000000000000c62c5c05fe03f0ae--