Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112178
MIME-Version: 1.0
References: <CAM0CcxjF3TzcFZegM3KvA07K_dQPnN=Mp-kkYK94Mja487KKtQ@mail.gmail.com>
 <02527028-FDC9-4CE8-869B-8EDBFABE6DEA@gmail.com>
In-Reply-To: <02527028-FDC9-4CE8-869B-8EDBFABE6DEA@gmail.com>
Date: Wed, 4 Nov 2020 06:42:31 +0200
Message-ID: <CAM0Ccxip9myz1P+3LEEbcOMc2zW_ks9O+ZfHA-jB--wn96HUZQ@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002611b805b3409cbb"
Subject: Re: [PHP-DEV] Nullsafe
From: zsidelnik@gmail.com (Eugene Sidelnyk)

--0000000000002611b805b3409cbb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

However, `null` value is not a good way to use a default value instead of
an object.
When it comes to polymorphism, we would like to avoid null checks from
being all around.
The same goes not only for `->`, but also return / argument type-hintings.

Why do we even need to know that object can be null? Null is just a special
case (there may be other special cases).
Does my customer code need to know about all special cases? Apparently not.
But still, we create another operator to handle this case.
It is ok when it comes to third-party libraries we don't have control over
and sometimes it could return null.

Yet this approach doesn't solve the primary problem. Polymorphism.

You can argue that `null` can be used to indicate that something was not
found.
But this is not the case for returning null. Here an exception should be
thrown.

When I would like to return some default value of an object, it can't just
be null (because it will pile up the code with ? signs).
I need to create a separate NullObject, which implements a particular
interface used at runtime, and return it's instance.
If an interface declares a returning object, then I have to write even more
boilerplate code for those objects.
It is all for such thing as the default "null" value for an object.

IMHO, simple things should be done in a simple way.
What I currently see is that to do a simple thing, I need to create `N`
`null`-classes, whose methods will eventually return `""` or `0` or `0.0`
or `false` or `[]` - generally speaking `null`.

On Tue, Nov 3, 2020 at 9:56 PM Claude Pache <claude.pache@gmail.com> wrote:

>
>
> > Le 3 nov. 2020 =C3=A0 17:38, Eugene Sidelnyk <zsidelnik@gmail.com> a =
=C3=A9crit :
> >
> > Hello, internals!
> > I am wondering why don't we use ordinary `->` operator with safe null
> > handling? Programmers will be more prone to return null values. And thu=
s,
> > in most of cases `?->` will replace `->`.
> > Why do we need another operator, if we can implement null safe in curre=
nt
> > operator without BC breaks?
>
> Hi,
>
> In a parallel world where people never commit bugs, yes, this is
> reasonable semantics.
>
> However, it happens more than once that a null value occurs by accident
> where an object is expected by the programmer. In this case, I very much
> prefer to have a Warning or an Error, typically handled by an error handl=
er
> which sends a bug report to the developer, then triggers an emergency sto=
p.
> That makes it much easier to locate and fix bugs.
>
> Of course, this debuggability facility have to be balanced with the
> inconvenience to having to write more code in cases where a null value is
> expected. Having to write =E2=80=9C?->=E2=80=9D instead of =E2=80=9C->=E2=
=80=9D in those cases is a minimal
> inconvenience. Here, I mean =E2=80=9Cminimal=E2=80=9D in a very literal w=
ay: exactly one
> character of difference.
>
> Also, there is the following benefit: When I write =E2=80=9C->=E2=80=9D, =
I am stating that
> the LHS value should never be null; when I write =E2=80=9C?->=E2=80=9D, I=
 am stating that I
> expect that the LHS is sometimes null. Thus, my code is documented in a
> very concise way (between zero and one character), which is an aid for an=
y
> future reader (including myself).
>
> Aside: The name =E2=80=9Cnullsafe=E2=80=9D is misleading. The operator is=
 not about
> safety, it is about handling null values in a concise way. In fact, in so=
me
> circumstances, sweeping an unexpected null value under the rug may be
> totally unsafe.
>
> =E2=80=94Claude

--0000000000002611b805b3409cbb--