Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92661
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kalpe.com from 209.85.213.175 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NqCt7J5hJU-XwO0GVjoY3qddpshKP68urXTKc23RZ15VQ@mail.gmail.com>
References: <CAKSD0w4jEH1uRaJ04RsWitV3jdKQxc05eRUxuF3hE8RGSw-nJw@mail.gmail.com>
 <57192F87.4080902@fleshgrinder.com> <CAKrrN66nVZp5=oB1vaQUOZ1=4723AGzzbQYK2wiCKi-xyF1=7w@mail.gmail.com>
 <571B6AF6.5030001@fleshgrinder.com> <CAKrrN65h6=q5E0VZK9ExA9STEFVrWXZMmS6jq59JfSV+xgvEgQ@mail.gmail.com>
 <CAFMT4NqCt7J5hJU-XwO0GVjoY3qddpshKP68urXTKc23RZ15VQ@mail.gmail.com>
Date: Sat, 23 Apr 2016 19:14:03 +0200
Message-ID: <CAKrrN64j0zOvDD4CD0151oHs56wji9qfLy6DvbyZRDm+bjm+tw@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2a0901f874205312a13b5
Subject: Re: [PHP-DEV] [RFC] Nullable Types
From: quim@kalpe.com (Quim Calpe)

--001a11c2a0901f874205312a13b5
Content-Type: text/plain; charset=UTF-8

On Sat, Apr 23, 2016 at 6:58 PM, Levi Morrison <levim@php.net> wrote:

> On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe <quim@kalpe.com> wrote:
> > 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
>
> 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.
>

--001a11c2a0901f874205312a13b5--