Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91983
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHvhOfjdOR7Obf4BHcN7aXbUnpkMEBh1m3cH=Eq5R66PeeuN1g@mail.gmail.com>
References: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
 <CAHvhOfjdOR7Obf4BHcN7aXbUnpkMEBh1m3cH=Eq5R66PeeuN1g@mail.gmail.com>
Date: Mon, 28 Mar 2016 23:15:04 -0300
Message-ID: <CANp8VMWb6drUyHM-GTA_CdS4mYmPZQRSkLiX-qT=r1sbcWq13Q@mail.gmail.com>
To: Kubo2 <kelerest123@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114144381b80f0052f269a42
Subject: Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time
 polymorphic methods
From: fnmartinez88@gmail.com (Facundo Martinez Correa)

--001a114144381b80f0052f269a42
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jakub,

Regarding the Null Object, I believe it to be a second hand solution.
Having a Null Object that returns 0, null, "" or false for every method
call, or a nil that acts as in Objective C that doesn't tell you when is
being poked the wrong way is the first step into madness. It will never
tell you about runtime errors, and you will find those errors once some
data that is being outputed from the systems gets into your
DB/Logs/Screen/whatever and just by chance you see that and say "Hey! that
wasn't supposed to be there!". Then all hell breaks loose, and you start
chasing code that never happens because your data will never be wrong and
will always gracefully degrade. I believe that pattern is a bad pattern and
humanity should feel bad about it. In fact, I believe it will be a feature
that will drive people away from PHP and not towards it.
Besides, the whole point of this idea I brought was to avoid checks that
the interpreter could catch. If I return a Null Object, I'm forced to
always ask for it.

Now, regarding the "NULL belongs to PHP and this language never aimed to
become Java" part. That is interesting because
a) I never wanted to be Java, and in fact, I want it to be as more
different to it as possible because I know what is bad and good and Java.
b) As far as I remember, from the beginning of PHP, NULL was as in C a
rename for 0. You could use 0, FALSE and NULL indistinctly. I'm not saying
to eliminate null. Null does serve some other purposes, specially when you
are managing memory, or bits, or whatever. I'm talking about making it
represent less things and make the language more expressive.

I hope transmitted my idea right. Thanks for the reply,
Facundo

On Mon, Mar 28, 2016 at 3:13 AM, Kubo2 <kelerest123@gmail.com> wrote:

> Hi Facundo Mart=C3=ADnez,
>
> I think the best solution to yourself described problem above would be
> the Null Object Design Pattern
> (https://en.wikipedia.org/wiki/Null_Object_pattern). In my opinion,
> NULL belongs to PHP and this language never aimed to become Java or
> similar.
>
> Jakub
>
> On 22 March 2016 at 01:34, Facundo Martinez Correa
> <fnmartinez88@gmail.com> wrote:
> > Hello,
> >
> > I am reaching you in order to obtain feedback on this RFC proposal.
> >
> > I have been playing with PHP 7 for a project in the company that I am
> > currently working for. One of the many drawbacks that I saw in PHP was
> the
> > there were no types. With type hinting I had confindence again in PHP.
> With
> > return type hinting a wasn't able to resist to try it. So here I am,
> making
> > a whole new platform entirely in PHP 7, using type hints in everything.
> > Arguments and returns alike. Given my tendency to language purity imagi=
ne
> > my surprise when my code inadvertently tryied to sneak a NULL into a
> method
> > expecting an object... And failing thanks to strictness in object and
> null
> > treatments in the new PHP 7. "SWEET!" I yelled.
> >
> > Now imagine my dumbfoundedness when a Repository of mine tryed to retur=
n
> a
> > NULL, and because it ought to return have returned a User, it threw a
> > TypeError. At first I said "sweet." But then I realized the problem.
> There
> > are many times where we need uncertainty. Code is a reflection of
> reality,
> > and as such, it must reflect uncertainty. NULL is a good enough way to
> > express nonexistence, albeit a bad one. We have been using it in code f=
or
> > years, but it is also used to say many things. Things that cause
> > uncertainty in the code. I receive a null, does it mean it doesn't
> exists?
> > That it will exist? Should I allow it? Is it a good value? I for sure
> don't
> > know. And in my experience, I have used it for many of those cases. And
> in
> > many situations that I'm not proud of, all of them at the same time.
> >
> > So I want to "return a NULL". I want to express uncertainty, a
> > nonexistence. But I want to express that I will return something. And I
> > want to have this NULL checking at interpretation time. I want
> everything,
> > and none of the drawbacks. As we say here in Argentina, I want the brea=
d
> > and the cake. What can we do to have it? After a bit of thought the May=
be
> > monad came to me.
> >
> > My experience in Haskell reminded me of this. To have a structure than
> > represents uncertainty, is the best way to take away the responsibility
> > from NULL. To express it in no other way. But my experience in Java has
> > taught me that Optional of something is not a good way to tackle the
> > problem. I still have to check if my Optional isEmpty. I still have to
> > check for null. That is because Java has that type erasure after
> > compilation time that doesn't allow me to play nice with polymorphism.
> But
> > maybe PHP can. Maybe PHP will give me the polymorphism at execution tim=
e
> to
> > discern an empty Maybe from the one that is not. So I don't have to che=
ck
> > for null ever again in my life. So my code can be free of nulls. So I c=
an
> > express uncertainty and nonexistance, while I return a User from my
> > repository.
> >
> > I hope someone would like this idea. I'm also open to suggestions.
> > Kind regards
> > Facundo Mart=C3=ADnez
>
>
>
> --
> Cheers,
> Kubis
>

--001a114144381b80f0052f269a42--