Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115577
MIME-Version: 1.0
In-Reply-To: <0643A227-98C4-437B-99A0-03951DA5EB93@newclarity.net>
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>
 <0643A227-98C4-437B-99A0-03951DA5EB93@newclarity.net>
Date: Sat, 24 Jul 2021 17:34:21 +0200
Message-ID: <CAOwTYAvAnCXsTOG2LQUuWggvgdJmFgBoUW=9bMjbh0Vd7-qRsg@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Tobias Nyholm <tobias.nyholm@gmail.com>, Nicolas Grekas <nicolas.grekas@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000011fda405c7e041ea"
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: krakjoe@gmail.com (Joe Watkins)

--00000000000011fda405c7e041ea
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is not a new feature. This is a detail of a feature that was not well
understood for whatever reason.

That is why we are willing to fix it after freeze.

I would ask anyone voting to vote on the basis of the detail and leave
timing to be the problem of release managers. Voting negatively because you
don't agree that we should fix it at this time might be considered harmful
(to the feature, which we already accepted).

Cheers
Joe

On Saturday, 24 July 2021, Mike Schinkel <mike@newclarity.net> wrote:

> > 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.
> >>
> >> 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 wha=
t
> you want.
> >>
> >> 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.
> >>
> >> 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 opinion=
s
> are in conflict.  If neither side will budge, nobody wins.
> >
> >
> > That is a strange attitude. You are saying that you rather see a releas=
e
> with a know flaw than actually trying to find the best solution.
> > 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.
>
> 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 an=
y
> real-world examples.  It claims that there were real-world examples, but
> did not show any.
> >>
> >> That message was also not part of the RFC.
> >
> > 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 nul=
lable
> intersection types are really needed =E2=80=94 you must has at least a fe=
w
> 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 m=
aintaining
> PHP libraries=E2=80=9D as I do.
>
> My understanding from all interactions on this list is that posters sayin=
g
> that something is important is (almost?) never sufficient. Instead it is
> incumbent upon RFC authors and RFC supporters to go the extra mile and ma=
ke
> 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 tryi=
ng
> 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:
> > If we don=E2=80=99t merge a version of this RFC in 8.1, PHP packages wi=
ll 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 P=
HP
> 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 expres=
s
> my API and do my major release then.
>
> That is not a real-world example of why nullable intersection types are
> really needed. That is an assertion about library maintainer's concerns w=
ho
> want nullable intersection types.
>
> 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.
>
> 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.
>
> 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 difficultie=
s,
> it cares about real-world use-cases that would provide reason why a featu=
re
> needs to be added to PHP.
>
> -Mike
>
> P.S. Also, what Deleu said.
>
>

--00000000000011fda405c7e041ea--