Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107698
Message-ID: <6A3CFA20-0209-427F-9842-D2C1D1FC43D3@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_61CA3CF4-E3F0-4732-8E29-9C95F449D203"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 25 Oct 2019 15:18:19 +0200
In-Reply-To: <CAN=NbAK7NrLg50YbCtkjU2XZKjif2R9Jbh9wn2W+GNvnX-ebfQ@mail.gmail.com>
Cc: Andreas Hennings <andreas@dqxtech.net>,
 Dan Ackroyd <Danack@basereality.com>,
 PHP internals <internals@lists.php.net>
To: Ken Stanley <dohpaz@gmail.com>
References: <CAN=NbAL5r7m3hSi5FgobHpxoOL0Rei=QbqegtJsRi8WnE4kX9A@mail.gmail.com>
 <CA+kxMuSNp+DeE+8+Wb+xSyMU0g-gV-3P-NEV_wdLNbFOxZk0Eg@mail.gmail.com>
 <CAN=NbAJfHzxW+bLACOD=CVg7y3wV26s+tp_cxCvR44W+4OWJ5A@mail.gmail.com>
 <CAH0Uv3FO3aTHHzQ+dLLc-q-mJzdjkR3wz-GcKVhWJ7pUTL2sqQ@mail.gmail.com>
 <CAN=NbAKaE8z8NM1sr4UjHkTcCzs9QwEWoU8OE-r-tRqWGdhCpQ@mail.gmail.com>
 <CAH0Uv3F_PMcNr50cCCz0fh6LMoVDyMNhrKZ3X4bP9678T2ESKA@mail.gmail.com>
 <CAN=NbA+6jEyEWneLiCazzmrmr0XhXy9Du+dZ029EDuHoiM+xFg@mail.gmail.com>
 <CAN=NbAK7NrLg50YbCtkjU2XZKjif2R9Jbh9wn2W+GNvnX-ebfQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] anti-coalescing-operator
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_61CA3CF4-E3F0-4732-8E29-9C95F449D203
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 25 oct. 2019 =C3=A0 04:36, Ken Stanley <dohpaz@gmail.com> a =C3=A9cri=
t :
>=20
> So far it seems like the biggest concern(s) is that we would most =
likely
> repeat the use of variables (nothing new), and that there are other =
ways to
> do the same thing (again, nothing new). And of course the most valid
> argument of all: adding more operators to the soup mix. Personally, I =
don=E2=80=99t
> see these as show stoppers, at least given that the idea is not too =
wild
> and out there.

Hi,

If you write

    A !?? B

instead of

    isset(A) ? B : null

you gain a *fixed* amount of 12 characters. The gain is proportionally =
low when A and B  are not trivial expressions. (The difference is fixed, =
because the proposed operator does not allow to reduce possible =
repetition of expressions.)

I don=E2=80=99t think that you gain readability or clarity. In =
particular, I am particularly confused with your last example:

> /**
> * @ParamConverter(name=3D=E2=80=9Capplication=E2=80=9D, ...)
> */
> public function myAction(Request $request, Application $application)
> {
>    $user =3D $application->getUser() !?? $this->getUser();
>=20
>   // ... do something with user, without worrying about it being null.
> }

because if $application->getUser() is null, then $user will be null, and =
you do have to worry about it being null, which makes me wonder whether =
there is some bug here. If it is really what you meant, spelling *null* =
explicitly will make it clearer, despite of being 12 characters longer. =
And if it is not what you meant, the bug will appear more readily:

/**
* @ParamConverter(name=3D=E2=80=9Capplication=E2=80=9D, ...)
*/
public function myAction(Request $request, Application $application)
{
   $user =3D isset($application->getUser()) ? $this->getUser() : null;

  // ... do something with user, without worrying about it being null. =
(sic)
}


=E2=80=95Claude


--Apple-Mail=_61CA3CF4-E3F0-4732-8E29-9C95F449D203--