Optional class is just a Value

[Peter Levart]

On 09/21/2012 05:16 PM, Paul Benedict wrote:
> You are conflating two different issues. Recommending Optional be an 
> interface, which is what I am doing, is about allowing java.lang 
> wrapper types to forego another wrapper. The usefulness of checking, 
> like you wrote in another thread, is an entirely separate matter.

The danger is, however, because the type hierarchy you are proposing, 
does not prevent from passing an "empty" Integer to code that expects 
the Integer to always be "present", that such scheme would result in 
even worse bugs than by passing a null value to code that always expects 
non-null values. In the later case you will at least get NPE while in 
the former, the "bug" would go unnoticed.

Regards, Peter

>
> Paul
>
> On Fri, Sep 21, 2012 at 10:12 AM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>     On 09/21/2012 04:53 PM, Paul Benedict wrote:
>>     Peter,
>>
>>     In regards to the java.lang wrapper types, those implementations
>>     of Optional (if it were an interface) would always have a value.
>>     The clear benefit is you don't have to wrap these already boxed
>>     values in a superfluous Optional wrapper.
>
>     But the clear drawback would be that badly written code, not
>     checking for .isPresent(), would use the value unnoticed, causing
>     all sorts of trouble (have you done any Objective-C?)...
>
>     Regards, Peter
>
>>
>>     On Fri, Sep 21, 2012 at 9:47 AM, Peter Levart
>>     <peter.levart at gmail.com <mailto:peter.levart at gmail.com>> wrote:
>>
>>         On 09/19/2012 05:47 PM, Paul Benedict wrote:
>>
>>             Brian,
>>
>>             I think the Optional class could be better named. I
>>             consider it a negative
>>             noun -- focusing on its ability to not contain a value.
>>             Really, it is
>>             nothing more than a bean for a value (and the value might
>>             be absent). It
>>             could have greater use than lambda so maybe it could be
>>             called something
>>             else.
>>
>>
>>         I think that Optional was not meant to be used in API-s as
>>         the type of a method parameters or as the type of fields,
>>          but only as the return type of methods with main usage
>>         pattern of calling it's methods in a chain. For that purpose,
>>         I think the name is fine.
>>
>>         And i think it is hoped that this will be the preferred use.
>>         If the Optional object is constructed late enough and
>>         discarded soon enough then method in-lining and escape
>>         analysis could optimize it's allocation on the stack (wishful
>>         thinking)...
>>
>>
>>
>>             Lacking a better suggestion myself, I thought it should
>>             be called "Value"
>>             ... and, if you refactored into an interface, you could
>>             possibly retrofit
>>             the java.lang type wrappers to implement it too.
>>
>>
>>         Huh, how would you do that?
>>
>>         What would the "not-present" Integer look like? Would it
>>         throw NullPointerException when calling .intValue()? ;-)
>>
>>
>
>