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
