Optional class is just a Value

[Paul Benedict]

On the contrary, I don't think there is any danger here. If you perform an
operation and get back <Optional> results, that's what you code against,
not any implementation of <Optional>.

Paul

On Fri, Sep 21, 2012 at 10:37 AM, Peter Levart <peter.levart at gmail.com>wrote:

>  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>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()? ;-)
>>>
>>
>>
>>
>
>