Primitive streams and optional

Tim Peierls tim at peierls.net
Sun Nov 25 10:22:04 PST 2012


I don't know what you're getting at. Sounds like this is moot, anyway.

--tim

On Sun, Nov 25, 2012 at 1:06 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 11/25/2012 07:02 PM, Tim Peierls wrote:
>
>  On Sun, Nov 25, 2012 at 12:25 PM, Remi Forax <forax at univ-mlv.fr <mailto:
>> forax at univ-mlv.fr>> wrote:
>>
>>         This would be more appealing with OptionalXxx, moving the
>>         Supplier argument away from the stream and onto the Optional
>>         object itself:
>>
>>             return s.least().or(() -> computeDefaultValue());
>>
>>
>>     sorry, but why do you want to create an Optional if there is no
>>     option. When you provide a supplier, if there is no result, the
>>     supplier is called to provide one so at the end there is always a
>>     value. I like intermediary state in a builder only when necessary.
>>
>>
>> When I use "Optional" I mean specifically the Guava semantics. I think
>> it's worth the extra object creation to be able to simplify the stream API.
>>
>> I understand that Doug and others disagree violently with me. :-)
>>
>>
>>     Optional is interesting only if it's a pseudo class recognized by
>>     the language that let you call any methods you want on it,
>>     i.e. if Optional acts as a reified null object. We are far from that.
>>
>>
>> Straw man argument.
>>
>
> ask yourself why Guava's Optional declares a method transform() by example.
>
>
>> --tim
>>
>
> Rémi
>
>


More information about the lambda-libs-spec-observers mailing list