Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91826
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.180 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
References: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
Date: Mon, 21 Mar 2016 14:27:55 -0600
Message-ID: <CAFMT4NpBYg-KpRiVkRzESmBXHNJqTQ43RgeJxZ9b=fYvNYxo_g@mail.gmail.com>
To: Facundo Martinez Correa <fnmartinez88@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time
 polymorphic methods
From: levim@php.net (Levi Morrison)

> 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 don't fully understand what you are asking for here. You want a
Maybe<T> to automatically become a T if it's not null or something?