Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79539
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain fb.com does not designate 67.231.145.42 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>
CC: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Nullsafe calls
Thread-Index: AQHQFATxvp9RjOsogUO8aMy5/EMi+5yJmRsAgAAfIAA=
Date: Wed, 10 Dec 2014 19:11:38 +0000
Message-ID: <583B9A4B-68FD-4FB1-B043-0D86E2480EAD@fb.com>
References: <95A581EE-A062-4926-BE44-BCA87FC9B356@fb.com>
 <9230CB24-22FC-4A0E-A9D5-F02523B65A02@ajf.me>
In-Reply-To: <9230CB24-22FC-4A0E-A9D5-F02523B65A02@ajf.me>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <C46FC4FB153A674ABC21708AF1FB81C5@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Nullsafe calls
From: jwatzman@fb.com (Josh Watzman)

On Dec 10, 2014, at 9:19 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi again,
>=20
> I was in favour of this, but upon further thought, I=92m not sure I am. I=
 remember I also initially liked it in Hack and then lost interest.
>=20
> First, how is this substantially different from catching an exception? Wi=
th Nikita=92s Exceptions in the Engine RFC, something like this would be po=
ssible:
>=20
>    try {
>        return $foo->bar()->qux()->elePHPant()->dance();
>    } catch (EngineException $e) {
>        return NULL;
>    }
>=20
> That would essentially do the same as what you=92re proposing:
>=20
>    return $foo?->bar()?->qux()?->elePHPant()?->dance();
>=20
> Are there many instances where there=92d be a substantial benefit to usin=
g ?-> versus catching an exception?

It's an API decision up to the implementors of the object. If you like usin=
g exceptions for *every* failure, then go for it, this syntax won't cost yo=
u anything or get in your way :)

However, for a lot of failures, I don't feel that exceptions are appropriat=
e. I tend to only use them for exceptional behavior -- usually, some failur=
e that needs to be propagated up a few levels up the stack, to an appropria=
te error boundary. This doesn't necessarily mean a completely unrecoverable=
 error, but it's *locally* unrecoverable. For things that are completely re=
coverable, returning null might be more appropriate and more lightweight, a=
nd then this nullsafe operator would be useful at that point.

Let me talk about a specific example to illustrate the difference, loading =
the User object in the context of FB news feed. Privacy checks are built in=
 to the User object, so you can't get a User you can't see, but how you wan=
t to deal with that failure depends on the callsite. User actually has two =
functions, one which returns null if you can't see the User, and the other =
which throws an exception. Suppose you are loading a news feed story, and y=
ou want to display the "actor" of the story (the person whose name appears =
at the top of the story). You'll want to use the "throw exception" variant =
there -- if you can't see the actor, you can't display the story at all, an=
d so you should throw an exception. An error boundary in the news feed infr=
a code is what catches the exception, several levels up, and just removes t=
hat single story from feed, and moves on. It's locally unrecoverable, thoug=
h globally we can still load feed. In the other direction, if you've got mo=
st of the story loaded and you just want the list of Users who have "liked"=
 the post, you probably want to use the returns-null version, and then use =
the ?-> operator to get the name of that User. It's completely locally reco=
verable, some User you can't see just gets left off the list of likers, gre=
at. We don't want to abort any operation at all, we can keep going; excepti=
ons are not really the appropriate tool to use here.

Maybe you disagree with the above, and the use of exceptions -- that's fine=
, I can totally buy arguments that the above isn't the way you or others wa=
nt to work. But not everyone does -- I at least think it makes sense to wor=
k the way I've described, and there are a lot of points on that spectrum, a=
nd this new operator makes it easy to operate at different points there.

> Second, not short-circuiting is rather unintuitive. I think most people w=
ould expect it to short-circuit. Note that ?? and isset() short-circuit, so=
 this would be inconsistent with existing NULL-checking operators. So why, =
then, are you proposing that it should not short-circuit? Is there some obs=
cure case that this makes easier? If anything, I=92d expect that short-circ=
uiting is the more useful behaviour. For example, take the following hypoth=
etical line of code:
>=20
>    $elePHPantParty->danceClub?->addToDanceFloor($elePHPantPool->remove())=
;
>=20
> If we have the short-circuiting behaviour, then if $elePHPantParty->dance=
Club is NULL, ->addToDanceFloor isn=92t called and an ElePHPant isn=92t rem=
oved from $elePHPantPool. On the other hand, if ->danceClub isn=92t NULL, -=
>addToDanceFloor is called and an ElePHPant will be removed from $elePHPant=
Pool.
>=20
> With the non-short-circuiting behaviour, this code would have to be longe=
r, and you couldn=92t use ?-> here. Instead, you=92d have to write this:
>=20
>    if ($elePHPantParty->danceClub !=3D=3D NULL) {
>        $elePHPantParty->danceClub->addToDanceFloor($elePHPantPool->remove=
());
>    }
>=20
> It is, admittedly, a hypothetical scenario, but it does demonstrate why h=
aving it not short-circuit is less useful. Are there any examples where sho=
rt-circuiting is a problem?

I think the short-circuiting behavior is the most intuitive, since it looks=
 like a method call, and evaluating arguments is what you do to prepare for=
 a method call -- and this RFC just makes the method call not actually happ=
en at the last moment. That said, although I feel pretty strongly about thi=
s, I also didn't find a good example where it mattered either way when I we=
nt looking at existing usages in Hack, and your example is indeed an intere=
sting one. Let me spend some more time looking for examples and get back to=
 you.

> Third, as has already been mentioned, this doesn=92t support ?-> for prop=
erties, which is both unintuitive (people will reasonably expect it to work=
) and makes it a lot less useful, because you won=92t always be dealing wit=
h method calls. While $foo?->bar()?->foobar() might work, what about someth=
ing like $foo?->bar?->foobar(), where one of the links in the chain is a pr=
operty? This is not at all an unlikely scenario.

If internals thinks this is a feature that would make or break the RFC, I'd=
 be willing to add it. I just figured that something smaller would be easie=
r to propose, implement, etc etc for my first RFC :)

> Finally, this may encourage bad code. As someone helpfully pointed out in=
 the reddit discussion, this encourages breaking the Law of Demeter, i.e. t=
hat objects should only talk to their immediate friends. Usually, long chai=
ns of method calls across multiple objects are not a good idea, yet the mai=
n benefit of this RFC is to reduce the boilerplate needed for that scenario=
.

I agree that long method chains are probably a bad idea, but one or two is =
fine in a lot of cases. But I very vehemently disagree that method chains a=
re *always* a bad idea (i.e., the Law of Demeter) -- or basically any hard =
and fast rule about programming, for that matter. It can be done tastefully=
, and for tasteful uses this reduces a lot of boilerplate. Basically every =
language feature can be abused, and I don't think this one is particularly =
more prone to abuse than anything else.

Josh