Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110361
MIME-Version: 1.0
References: <CAPyj-LBiaLyXfYGkW+h2eOCOdHYhJ16X=sx79v97x=0aUOXQZw@mail.gmail.com>
In-Reply-To: <CAPyj-LBiaLyXfYGkW+h2eOCOdHYhJ16X=sx79v97x=0aUOXQZw@mail.gmail.com>
Date: Thu, 4 Jun 2020 03:00:40 -0700
Message-ID: <CAPrKfG6d_W3ppnrkVzxHGkW7qFXLc_hvgEK5J2jTKkaKiyi9Ww@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Nullsafe operator
From: sarkedev@gmail.com (Peter Stalman)

> Hi internals
>
> I'd like to introduce another RFC I've been working on:
> https://wiki.php.net/rfc/nullsafe_operator
>
> It introduces the nullsafe operator ?-> that skips null values when
> calling functions and fetching properties. In contrast to the last few
> attempts this RFC includes full short circuiting.
>
> Let me know what you think.
>
> Ilija

Hi Internals,

Wouldn't it make more sense to make `isset` smarter?  So that it can
handle these situations just like it would with array access.  That
way you could use the null coalescing operator as well.

I don't see many situations where you would be selective in which
method in the chain you would want to make nullsafe and which ones you
wouldn't.  I think it would mostly be the entire chain, in which case
using `??` would be much less verbose.  In the few cases where you
want to be specific in which are nullsafe and which ones aren't you
can introduce one more variable.

Using the first example in the RFC this would visully be far nicer and
more readable about the intent:

    $country = $session->user->getAddress()->country ?? null;

Besides, shouldn't the example really be:

    $user->getAddressCountry();

I don't recall ever having to nest three levels like that example.  I
know the example is contrived, but wouldn't you know if you have a
logged in user or not?  Then just have a simple getter on the user for
what you need to check.  Chances are those variables you're trying to
save will be used elsewhere, or if not, refactor.

Also, assuming we have control over the User class, you can either
make address a property or use the magic getters (that many frameworks
have, love or hate them).  Even the new new accepted Constructor
Property Promotion would be helpful in facilitating that.  Basically
we can easily get around this problem already, and some frameworks do
it by default.  If not, writing one getter where you have to check a
few things is IMO far nicer than a long chain of possibly null
objects.

This is how I would solve the issue, assuming we're just in the
controller we don't make anything specifically for the User or Address
classes and no other uses for those specifically are needed.

    protected function getCountry()
    {
        $user = $this->session->user ?? null;
        if ($user === null)
            $this->redirectToLogin();

        if ($user->getAddress() === null)
            return null;

        return $user->getAddress()->country ?? null;
    }

Chaining that many objects together that may or may not be null just
seems so wrong to me.


My concern is that we would start seeing `?->` far too often and it
would promote some lazy habits, because people would add it "just in
case".  Personally I think it should be more explicit when we are
null-checking, and since the `->` object access usually doesn't have
spaces around it, it could "muddy the water".

It reminds me too much of the proposed "unary null coalescing
operator", which also reminds me of the error control operator.  Maybe
make the syntax `->@` to be more clear?

Sorry if I come off a bit harsh, but I don't see the need for this as
other solutions to this problem are more favourable IMHO.  As much as
it can be annoying sometimes, the `Call to a member function foo() on
null` is a very useful error.

Thanks,
Peter