Optional class is just a Value

[Paul Benedict]

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.

On Fri, Sep 21, 2012 at 9:47 AM, Peter Levart <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()? ;-)
>