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

On Mon, Mar 21, 2016 at 5:03 PM, Stephen Coakley <me@stephencoakley.com> wrote: > On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote: >> >> 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ínez > > > First of all, let me confess that I absolutely love monad (or composite) > types, and I greatly prefer a Maybe over something that may or may not be > null. There's a slight problem however, and something that will not be easy > to get around: a lack of generics. > > This is an issue with wrapper types in general in PHP, where you want to > wrap an object in some other type. You lose type safety on the inner object, > and so I tend to look for a more type-safe solution in PHP. There is already > a generics RFC out there (https://wiki.php.net/rfc/generics) but > implementing it won't be trivial. > > Implementing (or defining) a good Maybe type also depends on better > composite/enum types (https://wiki.php.net/rfc/enum is drafted, but doesn't > support what we need). The classical definition would be (hypothetical PHP > syntax): > > enum Maybe<T> > { > Some { > public function __construct(T $value); > public function isSome(): bool { > return true; > } > public function into(): T { > return $this->value; > } > }, > None { > public function isSome(): bool { > return false; > } > public function into(): T { > throw new Error(); > } > } > } > > Such a definition depends on two different things we don't have right now in > PHP. Maybe there's a simpler way, but hopefully you have a better > alternative? This requires you to query state with isSome(). This is hardly any different from a null case, just more code. We can already accurately distinguish between null and another value. If we want an option for safer PHP code I think we need a safer construct that requires exhaustive matching (such as Rust's match). I'm not sure how to pull that off.