Primitive streams and optional

[Remi Forax]

On 11/25/2012 06:01 PM, Tim Peierls wrote:
> On Sun, Nov 25, 2012 at 10:42 AM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 11/25/2012 02:14 PM, Doug Lea wrote:
>
>         On 11/21/12 12:59, Brian Goetz wrote:
>
>             OK, I think we have all the options and combinations of
>             options on the table.
>
>             A: OptionalInt min()
>             B: int min(int defaultValue)
>             C: int min() throws NSEE
>
>
>         I vote for renaming to make clearer that this is a reduction with
>         a basis, and then providing two forms:
>
>          int least(int ceiling); // return least value < ceiling, or
>         ceiling if none
>          int least(); // default ceiling == Integer.MAX_VALUE
>
>
>     I prefer :
>       int least(IntSupplier supplier); // return least value <
>     ceiling, or suplier.supply() if none
>       int least(); // default supplier == () -> Integer.MAX_VALUE
>
>     it's not rare to have a default value that also requires
>     computation and I don't want
>     to compute it if I don't need it.
>
>
> 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.

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.

>
> --tim

Rémi