Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54894936.9030003@gmail.com>
References: <95A581EE-A062-4926-BE44-BCA87FC9B356@fb.com> <9230CB24-22FC-4A0E-A9D5-F02523B65A02@ajf.me>
 <54894936.9030003@gmail.com>
Date: Thu, 11 Dec 2014 10:57:44 -0500
Message-ID: <CAFp73XuETdBbssKx6rv+=z3wvC_tBoYAyYmr_J7B66VBns7nLg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, Josh Watzman <jwatzman@fb.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ed20a722a2c0509f2d70c
Subject: Re: [PHP-DEV] [RFC] Nullsafe calls
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a113ed20a722a2c0509f2d70c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Not trying to demerit the proposal, but accepting ?-> and black magic just
seems wrong, very wrong.
You need to write defensive code, not rely on the language to do that for
you.

[]s,

On Thu, Dec 11, 2014 at 2:35 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > First, how is this substantially different from catching an
> > exception? With Nikita=E2=80=99s 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=E2=80=99d expect that short-circuiting is the mo=
re
> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--001a113ed20a722a2c0509f2d70c--