Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79552
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.153.30 as permitted sender)
To: Christoph Becker <cmbecker69@gmx.de>
CC: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Nullsafe calls
Thread-Index: AQHQFATxvp9RjOsogUO8aMy5/EMi+5yJmRsAgAAfIACAAFRDgIAABdyA
Date: Thu, 11 Dec 2014 00:33:50 +0000
Message-ID: <765E5B7F-6605-465F-81DC-BCB1C3D6E015@fb.com>
References: <95A581EE-A062-4926-BE44-BCA87FC9B356@fb.com>
 <9230CB24-22FC-4A0E-A9D5-F02523B65A02@ajf.me>
 <583B9A4B-68FD-4FB1-B043-0D86E2480EAD@fb.com> <5488E187.9010801@gmx.de>
In-Reply-To: <5488E187.9010801@gmx.de>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <775EC716CDDD7344BF68F234CBF9A2C9@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 4:12 PM, Christoph Becker <cmbecker69@gmx.de> wrote:

> Josh Watzman wrote:
>=20
>> However, for a lot of failures, I don't feel that exceptions are
>> appropriate. I tend to only use them for exceptional behavior --
>> usually, some failure that needs to be propagated up a few levels up
>> the stack, to an appropriate error boundary. This doesn't necessarily
>> mean a completely unrecoverable error, but it's *locally*
>> unrecoverable. For things that are completely recoverable, returning
>> null might be more appropriate and more lightweight, and then this
>> nullsafe operator would be useful at that point.
>=20
> FWIW, there is a third option: instead of returning null, return a null
> object[1].  That causes (slightly) more overhead, but it's quite
> flexible and works rather nicely without requiring the (IMO) ugly ?->
> nor exception handling.
>=20
> Consider a non-existent user "foo":
>=20
>  User::find('foo')?->getName() // returns null
>=20
>  User::find('foo')->getName() // could also return '' or 'Unknown user'

This is actually what the implementation does behind the scenes, but issues=
 with this approach actually being visible to userlevel code is what prompt=
ed the feature in the first place :) The biggest problem is that you can ac=
cidentally leak your null object, which causes the calling code to unexpect=
edly swallow errors; with the ?-> operator, you know you're always immediat=
ely using the null object, there's no way to hold onto it. Smaller problems=
 are that you either need a different null object for every object you want=
 to use this with, or a single general one with __call, which is ugly and h=
ard to optimize. It's also impossible to typecheck, but that was a problem =
for Hack and is pretty irrelevant to PHP.

It's also worth noting that doing this with a null object would have the sa=
me lack of short circuiting that I've been arguing for ;)

Josh