Primitive streams and optional

[Remi Forax]

On 11/25/2012 02:14 PM, Doug Lea wrote:
>
> ... returning to the question at hand ...
>
> 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.

>
> A similar pattern of using a recursion-ish basis value is
> available for all the other methods. And in many of them,
> you can provide a default relying on the natural identity
> element (as the minima reductions here).
>
> The notably odd-looking case of this is findAny, for
> which there is no plausible default basis. So either
> don't define the basis-less overload version, or default
> to exception:
>   int findAny(Pred pred, int basis);
>   int findAny(Pred pred) throws NoSuchElementException
>

again:
int findAny(Pred pred, IntSupplier int);
default int findAny(Pred pred) throws NoSuchElementException {
   return findAny(pred, () -> {throw new NoSuchElementException(); });
}

>
> (These are not new problems. All primitive collection
> frameworks out there (like Trove) hit this issue
> (for example for map.get(key)) and users seem to get
> used to it. Jarringness of a few constructions seems
> much better than the alternatives.)

:)

>
> -Doug
>
>

Rémi