On Sat, Apr 23, 2016 at 6:58 PM, Levi Morrison <le...@php.net> wrote:
> On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe <q...@kalpe.com> wrote:
> > Hi Richard,
> >
> > On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinder <p...@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("f...@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("f...@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
>
> Option is no better than a union type with null[1]. If a language
> requires an option to be unwrapped then it can do the same with some
> type or null. This is what Swift does. These things are exactly
> equivalent.
>
My point was about the developer receiving an Optional type, being less
error-prone than a nullable type. Not a language advantage.
>
> However in PHP we do not have generics, which means a nullable type is
> actually better because we can express the type that participates with
> null. With an Option type we cannot.
>
Yes, I was talking generically here, Option Types without generics-like
behaviour are a lot less useful
Nullable return types is indeed a better fit for PHP as I said
[1] At least with the behaviors here. If Option is a Traverable that
> returns 0 or 1 items then we can use that behavior to our advantage.
> Of course, we lose the ability to express the underlying option type.
>
