Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92659
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kalpe.com from 209.85.213.173 cause and error)
MIME-Version: 1.0
In-Reply-To: <571B6AF6.5030001@fleshgrinder.com>
References: <CAKSD0w4jEH1uRaJ04RsWitV3jdKQxc05eRUxuF3hE8RGSw-nJw@mail.gmail.com>
 <57192F87.4080902@fleshgrinder.com> <CAKrrN66nVZp5=oB1vaQUOZ1=4723AGzzbQYK2wiCKi-xyF1=7w@mail.gmail.com>
 <571B6AF6.5030001@fleshgrinder.com>
Date: Sat, 23 Apr 2016 18:40:55 +0200
Message-ID: <CAKrrN65h6=q5E0VZK9ExA9STEFVrWXZMmS6jq59JfSV+xgvEgQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec501620dacddc60531299c86
Subject: Re: [PHP-DEV] [RFC] Nullable Types
From: quim@kalpe.com (Quim Calpe)

--bcaec501620dacddc60531299c86
Content-Type: text/plain; charset=UTF-8

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

--bcaec501620dacddc60531299c86--