Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117561
Message-ID: <925590a9-afa8-7630-8201-cc561b2611fa@gmx.net>
Date: Thu, 21 Apr 2022 18:32:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com>
 <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
 <eed7bf5f-572f-11a4-51cd-542737cdacef@gmx.net>
 <CAFv4g+HOMThq1DKXFRA+_qGT6bw-fqzAvbwUADL-o-g4pwO6oQ@mail.gmail.com>
 <2035695b-b6b5-5982-a5ea-e85693e1f71f@gmx.net>
 <CAFv4g+Gh2yUdY1n+E3aAXKC46NxVoCLxmf=GR=+TK0f8myrpWg@mail.gmail.com>
 <a2f341b3-915a-aca2-12f9-88cdbee1ee41@gmx.net>
 <CAFv4g+FTvhDKD==yCsGU7hiMt6PmT78+ZiDXKbEpoDzT7hW4Cg@mail.gmail.com>
 <e63f5817-78bf-3490-202d-23022d81dc8e@gmx.net>
 <CAFv4g+Fx_K4usAmJZKUfOqfUDerbV6tFqSXbGypc=FF+1O_JKA@mail.gmail.com>
In-Reply-To: <CAFv4g+Fx_K4usAmJZKUfOqfUDerbV6tFqSXbGypc=FF+1O_JKA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: a.leathley@gmx.net (Andreas Leathley)


> There is another 3.5 years until PHP 9 is likely to come out, which is a
>> lot of time for people to adjust their codebase. I could even see an
>> argument for not promoting it to a fatal error in 9.0 if so many people
>> need more time.
>
>
> If it's deprecated, that is an intent to break... and if no other soluti=
ons
> present themselves, and the vote for this RFC fails... why would it be
> delayed? It will then be clear the Internals developers want this (they
> would have made an informed choice, and put their name to it).

A deprecation notice is fairly harmless. If in two years many projects
and many developers say that they need more time to fix these
deprecations and promoting them to errors would cause a lot of problems,
then it would be easy to prolong the period where it is only a
deprecation with a small RFC. By then more people will know if they are
impacted, many frameworks will have updated, and there will be a clearer
picture if this is such a big deal or not. Right now this is not clear -
I doubt most projects are using PHP 8.1, not even all
frameworks/libraries are compatible to PHP 8.1.


> Are you going to suggest any improvements? what have I missed? I'm tryin=
g
> to keep it short, because I know long RFC's can be a problem.

An RFC should cover the discussions held on this mailing list. From the
RFC howto:

"Update your RFC to document all the issues and discussions. Cover both
the positive and negative arguments."

Do you honestly believe you have done that? I have tried to discuss some
counterpoints and alternatives to your proposal, but none are mentioned
in the RFC. I also don't see the discussion points of other people in
the RFC. None of the alternatives to your proposal are mentioned in the
RFC - like changing the internal functions to accept null instead. There
have been quite a few suggestions and arguments made so far, and I don't
see them in the RFC.

I have discussed RFCs with a few people on this mailing list, sometimes
with very different opinions about a topic, and not always was there a
resolution to the topic at hand. Yet the discussions with you have been
the most frustrating so far, because you say you are open to arguments
and proposals, yet you do not seem to consider them at all - yet you
really seem to believe you are totally open-minded. I have been
impressed by a few people on this mailing list who I disagreed with
wholeheartedly, because I noticed with how much care they tried to relay
disagreeing arguments and other proposals in the RFC and how balanced
the RFCs were at the end. Your RFC seems totally incomplete to me and
mainly based on your made-up opinion. But at this point I don't think I
will get through to you in any way, which is why I will step out of this
conversation. If the RFC comes to a vote in the current conditions
though I will raise an objection that it does not represent the
discussions held on this mailing list and should be disregarded because
of that.