Optional class is just a Value

[Paul Benedict]

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.

Paul

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