Primitive streams and optional

Tim Peierls tim at peierls.net
Tue Nov 20 14:53:29 PST 2012


Actually, I'd prefer Optional<Integer>, but I didn't want to leave out the
other option.

On Tue, Nov 20, 2012 at 5:48 PM, Brian Goetz <brian.goetz at oracle.com> 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?
>
>
>
>
> 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"?
>>
>>
>>


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