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 hereOption 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. 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. [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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
