Optional class is just a Value
pbenedict at apache.org
Fri Sep 21 07:53:07 PDT 2012
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:
>> 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
> 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()? ;-)
More information about the lambda-dev