Primitive streams and optional

[David Holmes]

On 21/11/2012 8:56 AM, Remi Forax wrote:
> On 11/20/2012 11:48 PM, Brian Goetz wrote:
>> That's an option too, thanks for reminding me.
>>
>> Let me turn that one around. Would you be happy with a single min(def)
>> method that made you choose a default value always? Or would you find
>> it annoying and want something else too, for the cases when you know
>> there are elements?
>>
>> Would you spend any time wondering what the default value should be?
>>
>> Would you worry about how to distinguish between the case that it
>> returns the default value and the case when the default value actually
>> was the minimum (a la map.get())?
>>
>> I would guess that if you had min(defVal) you'd also want another
>> version (throwing? optional?) for the cases when some of the above
>> bother you?

Yes. min() throws; min(defVal) doesn't.

>
> min(def) and min() that throws a runtime exception are a good combo IMO,
> but because they can be generalize to min(IntSupplier), min(() -> def)
> and min(RuntimeException::new),

Aside:: are we really allowing Foo::new as a "method" reference for a 
no-arg constructor? If so I think I'd prefer Foo::Foo.

David
-----


> i think the best combo is:
> int min() that calls min(RuntimeException::new) by default
> and int min(IntSupplier).
>
> anyway, I think the same design should be applied to reduce, findFirst,
> min, max, average, etc.
>
> Rémi
>
>>
>>
>>
>> On 11/20/2012 5:43 PM, Tim Peierls wrote:
>>> What happened to min(int defval)? That way the library doesn't have to
>>> decide on a good default, but the user can.
>>>
>>> --tim
>>>
>>> On Tue, Nov 20, 2012 at 5:14 PM, Brian Goetz <brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>> We're working through implementing the primitive specialization of
>>> streams now. So far, its pretty straightforward; many of the ops on
>>> reference streams have an obvious analogue (e.g., filter, map,
>>> forEach), and many are just not applicable (e.g., into, since there
>>> are no primitive collections.) There are also a number of
>>> additional methods that make sense on primitive streams, such as
>>> sum(). (You can see the work in progress in the lambda repo.)
>>>
>>> The tricky ones are the ones that return some sort of Optional. For
>>> sum() there is an obvious value to return if there are no elements
>>> in the stream (zero), but for min/max/average, it would require more
>>> distortion to avoid optionality. We can't expect users to know a
>>> priori whether the stream is empty. Example:
>>>
>>> int firstOrderNumber
>>> customers.flatMap(c -> /* c.orders */)
>>> .map(o -> o.getOrderId())
>>> .min();
>>>
>>> The options are:
>>>
>>> - throw NSEE
>>> - make up a bad default (e.g., MAX_VALUE for min)
>>> - return an Optional<Integer>
>>> - return an OptionalInt
>>>
>>> The first two are pretty bad, and are asymmetric to the reference
>>> streams. Creating N new OptionalXxx classes is kind of annoying and
>>> bloaty. (There's an argument to be made for "Well, we're boxing
>>> once at the end anyway, boxing twice with Optional<Integer> isn't
>>> terrible.") Though I suspect that will be an ongoing irritant. Are
>>> there other "options"?
>>>
>>>
>