Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115576
Message-ID: <0643A227-98C4-437B-99A0-03951DA5EB93@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_98A0672B-CD9F-482D-A4F3-B02567730D60"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Sat, 24 Jul 2021 09:11:58 -0400
In-Reply-To: <B7C29E12-26AB-43BC-B945-95A33D4CF6A9@gmail.com>
Cc: Nicolas Grekas <nicolas.grekas@gmail.com>,
 PHP Internals List <internals@lists.php.net>
To: Tobias Nyholm <tobias.nyholm@gmail.com>
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <353F9140-7E59-4CD4-95D3-9BA8F9CA6C29@newclarity.net>
 <43D8F75F-09B0-4AE4-A9EB-8775E231B367@gmail.com>
 <94F0E6DA-8C69-402D-B6B2-5EBDEB6638FB@newclarity.net>
 <B7C29E12-26AB-43BC-B945-95A33D4CF6A9@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_98A0672B-CD9F-482D-A4F3-B02567730D60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jul 24, 2021, at 1:33 AM, Tobias Nyholm <tobias.nyholm@gmail.com> =
wrote:
>> If you are not willing to compromise you will probably get nothing.
>>=20
>> It is relevant because I was trying to get you to ask yourself if you =
would be happier if you get half of what you want rather than none of =
what you want. =20
>>=20
>> Because there is a very real possibility you will get none of what =
you want if the RFC requires the syntax so many have objected to.
>>=20
>> BTW, I do not have a strong opinion either way, but since I see than =
many do have a strong opinion I was trying to play arbitrator between =
two sets of people who each have very entrenched opinions where their =
opinions are in conflict.  If neither side will budge, nobody wins. =20
>=20
>=20
> That is a strange attitude. You are saying that you rather see a =
release with a know flaw than actually trying to find the best solution.=20=

> The release will be in 4 months. There is a process to clearly find =
issues like this. There is plenty of time to review this RFC and release =
it in beta 2 and let people test it. This is not a last minute thing, =
the process is designed for this.=20

That is begging the question. It is not a "known flaw" =E2=80=94 it is a =
perfectly fine option =E2=80=94 it is just not your preference.  Arguing =
the syntax is squarely in the realm of bike-shedding.

>> That message mentioned the need in abstract, but it did not provide =
any real-world examples.  It claims that there were real-world examples, =
but did not show any. =20
>>=20
>> That message was also not part of the RFC.
>=20
> The first paragraph under =E2=80=9CRational=E2=80=9D mentioned this: =
https://wiki.php.net/rfc/nullable_intersection_types#rationale =
<https://wiki.php.net/rfc/nullable_intersection_types#rationale>
I see no code examples showing real-world use-cases in the "Rational" =
section, I just see an abstract assertion by the author explain why they =
believe it is needed.

I don't get the pushback on providing real-world use-case examples. =
Clearly with your work in Symfony =E2=80=94 given the assumption that =
nullable intersection types are really needed =E2=80=94 you must has at =
least a few examples.  Why not provide them?

> In my world maintaining PHP libraries, it is obvious that 7.0 was =
missing this feature. As Benjamin mentioned, you could see that all =
libraries that migrated from 5.x just skipped 7.0 and went straight to =
support 7.1. I did the same for all my packages because of this reason. =
I made a misstake to assume that everybody had the same =E2=80=9Cworld =
of maintaining PHP libraries=E2=80=9D as I do.=20

My understanding from all interactions on this list is that posters =
saying that something is important is (almost?) never sufficient. =
Instead it is incumbent upon RFC authors and RFC supporters to go the =
extra mile and make a strong case for why something is needed.  And thus =
far, I have not seen any actual cases where it is needed, I have only =
heard assertions.

Note I am not against this. I tend to prefer more functionality in a =
language, not less.  So by asking you to give examples I am actually =
trying to help you make your case. And it is puzzling to me why you are =
pushing back so hard when I ask for use-cases.

> So the =E2=80=9Creal world examples=E2=80=9D you are looking for is:=20=

> If we don=E2=80=99t merge a version of this RFC in 8.1, PHP packages =
will not take leverage of the inspection types until PHP 8.2. The reason =
for a package to drop PHP 7 support is to be able to use the cool =
features in PHP 8. This will require a major release (something all =
maintainer should do sparsely). Why would I do a new major release if I =
cannot properly define my API (interfaces)? I rather wait to next PHP =
version where I can express my API and do my major release then.=20

That is not a real-world example of why nullable intersection types are =
really needed. That is an assertion about library maintainer's concerns =
who want nullable intersection types.=20

It is not code nor does it have anything mention of how any use-cases =
where nullable intersection types would be applied.

> Sorry if I sounded (or keep sounding negative). I appriciate you and =
everybody else participate in this discussion. We are all trying to make =
PHP better and we are all trying to move this RFC forward.=20

Then give some actual examples instead of just repeating assertions that =
this is needed and if you don't get it you believe it will make your =
life more difficult as a library maintainer.=20

There are tens of things that make my life difficult every day I program =
in PHP, but this list doesn't care about my own or any of our =
difficulties, it cares about real-world use-cases that would provide =
reason why a feature needs to be added to PHP.

-Mike

P.S. Also, what Deleu said.


--Apple-Mail=_98A0672B-CD9F-482D-A4F3-B02567730D60--