Re: [RFC][Discussion] Objects can be declared falsifiable

From: Date: Wed, 15 Jul 2020 16:54:36 +0000
Subject: Re: [RFC][Discussion] Objects can be declared falsifiable
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-111026@lists.php.net to get a copy of this message
On Wed, Jul 15, 2020, at 11:43 AM, Marco Pivetta wrote: > Hey Larry, > > On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield <larry@garfieldtech.com> > wrote: > > > 1) return null, which is a non-type, and thus you need to make the return > > type ?User or User|null, which means the caller *must* always check it's > > nullness. > > > > Allowing an object to falsify itself is a 4th, more type-safe option. It > > lets you return an object that both fails a boolean check (like null) but > > also has default values in it for the base case. A user object likely > > wouldn't use that, but a value object like an Address very well could. > > > > Until we can support for-reals monads (which would require enums and > > generics to do properly; the former is possible the latter is very hard), > > it's the best option we have for more type-safe returns. > > > > Adding a "falsey" state for code that expects `is_object($foo) === (bool) > $foo` seems to be a massive BC break to me, and reduces type safety of > boolean operators (and checks) by expanding the object type and > all > operators and expressions that can interact with it. > > In general, ?T is very much equivalent to Maybe > T I disagree entirely. The value of a Maybe over just null is 1) You can bind to it even if the result is empty; the "if is null" check gets abstracted away from the main code. 2) You are forced to unwrap/extract the value if you're not just binding, which makes it less likely you'll forget to check if it's null. --Larry Garfield

« previous php.internals (#111026) next »