java.util.Optional fields
Peter Levart
peter.levart at gmail.com
Fri Sep 21 09:25:07 PDT 2012
On 09/21/2012 05:20 PM, Kevin Bourrillion wrote:
> On Fri, Sep 21, 2012 at 8:05 AM, Peter Levart <peter.levart at gmail.com
> <mailto:peter.levart at gmail.com>> wrote:
>
> The 3-state Optional (non-null value, null value, empty) has a benefit
> in that it can express the 3rd option in a way that does not force
> using
> exceptions.
>
>
> That is correct.
>
> - A plain old T reference has only one kind of not-there: null.
> - A Guava Optional<T> reference has two: null, and absent.
> - The proposed Optional<T> has three: null, absent, and contains-null.
I had the impression that an Optional<T> reference would never be null.
You can not enforce that, but as Stream is currently implemented, it
never returns null where the return type is Optional<T>.
So in context of Stream(s) we have 4 choices:
a) don't allow null as elements of Stream (throw NPE if such element
encountered), the return type of .findFirst() is T and returns null if
no such element exists
b) don't allow null as elements of Stream (throw NPE if such element
encountered), the return type of .findFirst() is Optional<T> and never
returns null, but an empty Optional when no such element exists or
non-empty optional when it exists.
c) allow null as elements of Stream, the return type of .findFirst() is
T and throws NoSuchElementException when no such element exists or
returns the possibly null element if it exists.
d) allow null as elements of Stream, the return type of .findFirst() is
Optional<T> and never returns null, but and empty Optional<T> when no
such element exists or an Optional with possibly null element if it exists.
I thought that the intent was to do d), but it seems that as it is
implemented, we have b).
I guess it all boils down to whether we would allow null elements as
elements of Stream or not.
Regards, Peter
>
> If this is an improvement, why not four? Of course, that's
> ridiculous. So we're really suggesting that three is somehow the
> magic number of logical kinds of "not-there" that should be enabled?
>
> And what of all the users who only wanted two? One kind of not-there
> will be represented as Optional.absent() for sure, but the other could
> be either plain null or optional-containing-null, and neither approach
> is obviously better than the other, so users will probably end up
> using a mixture.
>
> Result: proper usage of this Optional will really depend on JSR-308
> annotations. To get the behavior Guava gives them today, users will
> need to use Optional<@Nonnull T>.
or better @Nonnull Optional<T> ...
>
> Guava's been getting along fine with its Optional that can't hold
> null. When users have three kinds of not-there, we suggest that
> they're /really/ better off making their own type that actually
> defines what each of these is really supposed to /mean/ more clearly.
>
Do users of Guava pass null values where Optional is expected?
Regards, Peter
More information about the lambda-dev
mailing list