java.util.Optional fields

[Vitaly Davidovich]

I disagree, as I mentioned on that other thread as well. :) A lot of types
can be considered as containers in the abstract - that's not a very
interesting distinction.  In this case, a library class is added to make a
language feature a bit less error prone (i.e. null and associated NPEs that
unsuspecting developers hit).  Given this, Optional sounds correct and more
targeted.  Moreover, given that Optional is meant to replace use of null, I
don't think it should allow null as a valid value.  If null and "absent"
have different meaning in a given scenario then don't use Optional for
those.

Sent from my phone
On Sep 21, 2012 9:00 AM, "Paul Benedict" <pbenedict at apache.org> wrote:

> > On Fri, Sep 21, 2012 at 7:19 AM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
> > Why not implement this like Guava with two concrete subtypes of Optional:
> > Present and Absent? It seems cleaner and I don't think performance will
> be
> > worse as compiler will only ever see two possible receivers and can use a
> > PIC to eliminate calls via vtable in those cases.
>
> I think this thread touches on an email I wrote earlier, which is Optional
> is not really a good name choice. It's all focusing on its potential lack
> of value rather than just being what it is -- a container.
>
> > On Sep 21, 2012 7:42 AM, "Peter Levart" <peter.levart at gmail.com> wrote:
> > Maybe the intention was to allow null values to be wrapped in non-empty
> > Optional? In that case the check for non-null in constructor is wrong...
>
> Peter, I agree that a present value of null and an absent value (defaults
> to null) need to be differentiated. Yes, it looks wrong.
>
> Paul
>