Re: RFC Proposal: Maybe monad and execution time polymorphic methods

On 3/21/16 10:23 PM, Côme Chilliet wrote:

Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a écrit :

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.

If your function is supposed to return a User and can’t, maybe it should throw an Exception. Just wanted to point out it can be a good alternative to returning NULL for error handling. Côme

In the PHP 7 and typing presentations I've been giving[1], I've advocated either: 1) Throw an exception if the rest of the code is going to break anyway. 2) Define an empty object with matching interface if you want an equivalent of 0/empty string. While a monad sounds cool, it doesn't seem like the necessary language infrastructure is there for it at the moment. [1] My most recent talk that has a section on returns: https://youtu.be/rWDY4-LJils?t=2m38s (that's where the return type segment starts) Slides: https://www.palantir.net/presentations/midcamp2016-php7/ -- --Larry Garfield