Optional class is just a Value

[Peter Levart]

On 09/21/2012 07:01 PM, Paul Benedict wrote:
> 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

Ah, I see. You want Integer to be Optional<Integer> by implementation 
not by type. You could cast, but this would not be recommended. The 
not-present instance disguised as a singleton public static final field 
of type Optional<Integer> inside Integer class:

public class Integer {
   public static final Optional<Integer> NONE = ...


Ok, another problem with such scheme is limited usability. For example 
it would not be possible to use it in generic APIs (like Stream for 
example) without resorting to awkward "factory" or Class parameters.

Peter

>
> On Fri, Sep 21, 2012 at 10:37 AM, Peter Levart <peter.levart at gmail.com 
> <mailto: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 <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()? ;-)
>>>
>>>
>>
>>
>
>