Re: [RFC] Nullable Types

Hi Richard, On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinder <php@fleshgrinder.com> wrote: > On 4/22/2016 11:42 AM, Quim Calpe wrote: > > IMHO, the point of Optional types is the intention, if you get an > > Option<Foo> from a method, you have to deal with a None branch. Of course > > you can just unwrap and go on, but it's a developer decision to do that, > > not an oversight as using a Foo|null (or ?Foo) as an object directly. > > > > IMOH, the point of ?T is the intention, if you get a null from a method, > you have to deal with a null branch. Of course you can just ignore it > and go on, but it's a developer decision to do that, not an oversight as > using a Option<T> as an object directly. > > Sorry, but this works in both directions. The problem is not null, the > problem is that there is no system that warns you (e.g. a compiler) > about the missing null check. I think that Ceylon solved this problem > extremely nicely without the introduction of something special. > Of course, this works in both directions, but I see a value in Option types: function getByEmail(string $email) : ?User {} $user = getByEmail("foo@bar.com"); echo $user->getName(); I neglect the nullable return but works at first , all fine... .. a week later... "Warning: Call to a member function getName() on null" With Option type: function getByEmail(string $email) : Option[User] {} $user = getByEmail("foo@bar.com"); echo $user->getName(); IDE could warn me and It crashes right away, an option type must be unwrapped so I get the "intention" immediately :) > > function fn(): ?T {} > > $x = fn(); > if (is $x T) {} > else {} > > Not doing as above is a compiler error in Ceylon. However, I already > wrote multiple times that there are already statical code analysis tools > available that can find exactly such things in your code. One just needs > to use them. > That's really nice > > -- > Richard "Fleshgrinder" Fussenegger > > Option types are nice, but I feel we are going a bit off-topic. Option types work better with other niceties like for comprehensions, pattern matching... And I don't see PHP going that route in the near future, and probably It's not okay for PHP to go that route... Nullable return types is a better fit for PHP, null has been in the language from the beginning, I agree here