Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120553
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>
In-Reply-To: <CAH5C8xXY3-YjbO6Dq20hRmLUETA3FEpx+rk4+9J3LwO10R6ojA@mail.gmail.com>
Date: Sat, 10 Jun 2023 09:31:24 +0200
Message-ID: <CAH5C8xW2eXsC5tY5zkZo9TE2QsvvDjdaLzjjZiGKHSJZq6qFJw@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Cc: Rowan Tommins <rowan.collins@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b9aa8005fdc179ba"
Subject: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000b9aa8005fdc179ba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm forwarding my mails which I managed to only address for Rowan:

Hi Rowan,


> If we go down that route, perhaps we should come up with a corresponding
> name for the object based version - "session_set_handler_object" perhaps?
> That would also mean the deprecation messages can be much simpler: if
> you're using the old name, you need to do something.
>

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.

Then I guess we should just pack up and go home, because right now PHP
> doesn't even have an official static analyser, let alone a mandatory one;
> and the evolution of Hack shows just how much the language would need to
> change for such a tool to guarantee full coverage.
>

I'm not 100% sure an official static analyser would be needed. I think it's
already a good situation to have very well usable and maintained userland
implementations, which we do have. After all, we neither bundle Composer
or PHPUnit.

To expand on my previous statement in my other main: I don't say that
everyone uses static analysers.... I know many people don't... My message
would have rather been that bugs don't cost enough for these projects
if they don't have to actively prevent the introduction of bugs via static
analysis. I have realized in the meanwhile though that there may be many
other reasons why someone doesn't use these tools, so I think this argument
of mine is invalidated.

I think Claude is taking the same premise, and reaching a  different
> conclusion: returning true is consistent with the other methods on the
> class, and that consistency makes it more predictable and more accessible=
.
>

However, as George highlighted (I also tried, but most probably I couldn't
convey my message), declaring true return types is an intermediary step
before changing them to void. So replacing the old IntlCalendar methods
having "incorrect" return types with new ones having the "correct" return
types is a very nice by-product of this RFC, since we (and users) don't
have to deal with the return type migration separately at a later point of
time.
I still think that the benefit of immediately using void for the new
methods outweighs the risks.

Regards:
M=C3=A1t=C3=A9

--000000000000b9aa8005fdc179ba--