Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91824
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.179 as permitted sender)
MIME-Version: 1.0
Date: Mon, 21 Mar 2016 17:04:30 -0300
Message-ID: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a113e7ff2ed6952052e949ba4
Subject: RFC Proposal: Maybe monad and execution time polymorphic methods
From: fnmartinez88@gmail.com (Facundo Martinez Correa)

--001a113e7ff2ed6952052e949ba4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 imagine
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 return 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 for
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 bread
and the cake. What can we do to have it? After a bit of thought the Maybe
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 time to
discern an empty Maybe from the one that is not. So I don't have to check
for null ever again in my life. So my code can be free of nulls. So I can
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

--001a113e7ff2ed6952052e949ba4--