Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79560
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 as permitted sender)
Message-ID: <54894936.9030003@gmail.com>
Date: Wed, 10 Dec 2014 23:35:18 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, Josh Watzman <jwatzman@fb.com>
CC: PHP internals <internals@lists.php.net>
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>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Nullsafe calls
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> First, how is this substantially different from catching an
> exception? With Nikita’s Exceptions in the Engine RFC
> (https://wiki.php.net/rfc/engine_exceptions_for_php7), something like
> this would be possible:
> 
> try { return $foo->bar()->qux()->elePHPant()->dance(); } catch
> (EngineException $e) { return NULL; }

This actually is not a good code. Exceptions should not be used for
something that is expected and normal, they should rather be used for
situations where you code does something you could not predict.
Programming for exceptions is usually bad style, and designing code flow
expecting exceptions is usually bad idea. So I'd actually prefer being
able, like, say, in Groovy, to say "try to call this long chain of
whatever, but if it doesn't work out, just give me null". Of course, it
is not for carefully controlled code with error reporting, but for some
prototype code dealing with dirty data I found such shortcuts be rather
helpful. I'd like PHP to be more Groovy and less Java, in other words ;)

> Second, not short-circuiting is rather unintuitive. I think most
> people would 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 obscure case that this makes
> easier? If anything, I’d expect that short-circuiting is the more
> useful behaviour. For example, take the following hypothetical line
> of code:
> 
> $elePHPantParty->danceClub?->addToDanceFloor($elePHPantPool->remove());

I agree, for this feature I think it is a must that it would have no
magic like evaluating code way past the first null in ?-> chain. As soon
as there's null on the left of ?->, we should be done and return null,
it should work just like the if would work. In fact, it can even compile
to the same code as if() would.
-- 
Stas Malyshev
smalyshev@gmail.com