Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107687
MIME-Version: 1.0
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>
 <CAP=w73XojOXYayXaXsFzoqD-iCq-CMWMAsV=1ie6tuTv+rkxEQ@mail.gmail.com>
 <CAN=NbAKO7ZGCff3DKSEtw1mox9J=j7u=Xke-0CE0fJOK1KsbNw@mail.gmail.com>
 <5db21f54.1c69fb81.eda99.d428SMTPIN_ADDED_MISSING@mx.google.com>
 <CAN=NbALwq=t1S2BukRp1mzbehq8ixRyKe-zHF2905K5eHCJYhw@mail.gmail.com> <09AB755E-4A05-4D19-8276-BFD658D92EED@newclarity.net>
In-Reply-To: <09AB755E-4A05-4D19-8276-BFD658D92EED@newclarity.net>
Date: Thu, 24 Oct 2019 22:31:04 -0400
Message-ID: <CAN=NbALY7yE1o_aRVytNwW-g-gFVEJH8sBvKdtNPdEtmSqKOFA@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c3e6a10595b2f133"
Subject: Re: [PHP-DEV] [RFC] anti-coalescing-operator
From: dohpaz@gmail.com (Ken Stanley)

--000000000000c3e6a10595b2f133
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 24, 2019 at 8:54 PM Mike Schinkel <mike@newclarity.net> wrote:

> On Oct 24, 2019, at 6:49 PM, Ken Stanley <dohpaz@gmail.com> wrote:
> I would be keen to see the more expressive techniques that retain the
> succinctness of having a not-null coalescing operator.
>
>
>
> When I read your first example, I immediately thought I would handle your
> example in this way:
>
> $user->setFName( $_SERVER[ 'fname' ] ?? null );
>
> $user->setLName( $_SERVER[ 'lname' ] ?? null );
>
> $user->setMName( $_SERVER[ 'mname' ] ?? null );
>
> $user->setPhone( $_SERVER[ 'phone' ] ?? null );
>
> $user->setEmail( $_SERVER[ 'email' ] ?? null );
>
>
> Admittedly it does not require the functionality of your proposed
> operator, and it delegates the null handling to the set*() methods, but i=
t
> is more succinct and does not require duplicating `$_SERVER[ '*' ]`, so
> it would be a winner for me.
>
>
The problem here is that null values may or may not be valid inputs for the
setters. Assuming for one moment that the setters do allow null, what does
that mean for the underlying model? Is null to mean that it=E2=80=99s under=
? Or is
null just another possible value?

Using !?? to only call a setter if there is a non-null value is very
important in many circumstances - my original example was to illustrate a
succinct way to implement a REST PATCH HTTP request, where only fields with
values get updated - in other words, you don=E2=80=99t want to set other fi=
elds to
null because you want to retain their original values; not overwrite them.
Overwriting values with null is a valid use case, but not for this operator
(not necessarily).

Null means nothing, no value, or better: not answered. This is distinctly
different than =E2=80=98=E2=80=99, false, or 0. Those are explicit response=
s to a question.
Null Just means no data.


> I also do not mind putting more effort into writing functions if it means
> less effort required to call the functions. But maybe that is just me?
>
>
But if you don=E2=80=99t have to, then why would you? I=E2=80=99m all for c=
larity and
expressiveness. But I=E2=80=99m also for simplicity and being as succinct a=
s
practically possible.


> Your 2nd example was more compelling for me, but Sara's nullsafe calls RF=
C
> uses a syntax that is more clear and obvious to me.
>
>
I am a Symfony developer, and as such I like to utilize annotations (bear
with me). They have a ParamConverter annotation that can automatically look
up an entity based on the type hint given to a controller action.

If the parameter is null able, I may need to add an if condition to look up
a sane default value when the parameter comes through as null. It would be
much more succinct (and less error prone) to be able to say something like

/**
 * @ParamConverter(name=3D=E2=80=9Capplication=E2=80=9D, ...)
 */
public function myAction(Request $request, Application $application)
{
    $user =3D $application->getUser() !?? $this->getUser();

   // ... do something with user, without worrying about it being null.
}


> Is there a 3rd or 4th use-case you have that are unlike the first two?
>
>
I will let you know when I think of them. I totally understand how much
easier it is for others to conceptualize with good examples. I want to be
concise and relevant at the same time, and that=E2=80=99s actually pretty
difficult. :-)


> -Mike
>
>
>
> --
"Do not go gentle into that good night. Rage, rage against the dying of the
light." =E2=80=94 Dylan Thomas

--000000000000c3e6a10595b2f133--