Optional -> OptionalResult

[Zhong Yu]

I like Result<T>. I think it should be able to carry an Exception too.
API authors who don't care to give an exception use the default
exception.

    interface Result<T>

        // return a failure with a NoResultException
        public static Result<T> none(){ return NONE; }



On Tue, Jun 4, 2013 at 10:13 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> Optional is, and will continue to be, a key debating point for those
> arguing for more FP. The pressure to make it more powerful will
> continue, especially given similar named features in other languages.
>
> Meanwhile I continue to fear Map<Optional<List<Optional<String>>> and
> the like. The generics type system in Java simply isn't good enough to
> be doing anything like that, even if it were remotely desirable.
>
> Where the class is useful is in the return position. As Brian says "I
> think where we've tried to land is: do things that encourage people to
> use Optional only in return position".
>
> However, the one thing that hasn't been done is to name it as such.
> Simply rename "Optional" to "OptionalResult", or just "Result" and
> many of the issues go away. Those from an FP background will clearly
> see it as something different (if related) and continue to be
> disappointed (Java isn't going to satisfy them no matter what). More
> importantly, Java developers will only use the class in the return
> type position, simply because of its name.
>
> Of course it doesn't prevent Map<Result<List<Result<String>>>, but it
> makes it much less likely just because the name no longer makes sense.
> If it is used in that way, its probably because it really is a
> collection of earlier results.
>
> Finally, I'd note that if named Result/OptionalResult, I don't overly
> mind which set of methods are on it or that it is a box. So long as
> there is the ability to query it using a simple if statement.
>
> Stephen
>
>
>
> On 24 May 2013 21:15, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Optional has obvious upsides and downsides.  Some of the downsides are:
>>  - It's a box.  Boxing can be heavy.
>>  - The more general-purpose value-wrapper classes you have, the more some
>> people fear an explosion of unreadable types like
>> Map<Optional<List<String>>, List<Optional<Map<String,
>> List<Optional<String>>> in API signatures.
>>
>> I think where we've tried to land is: do things that encourage people to use
>> Optional only in return position.  These methods make it more useful in
>> return position while not increasing the temptation to use it elsewhere any
>> more than we already have.  Hence "mostly harmless".
>>
>>
>> On 5/24/2013 4:10 PM, Tim Peierls wrote:
>>>
>>> On Fri, May 24, 2013 at 3:20 PM, Brian Goetz <brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>>     Proposed spec for methods on Optional, which would have the obvious
>>>     counterparts in Optional{Int,Long,Double}.
>>>
>>>     These methods are known to be useful and seem mostly harmless now
>>>     that other things have settled.  (I don't think they greatly
>>>     increase the moral hazard of Optional in general, and they do make
>>>     it more expressive.)
>>>
>>>
>>> I'm in the curious (unique?) position of both desperately wanting
>>> Optional and desperately *not* wanting lots of additional methods like
>>> these. If the price of having Optional is the presence of these methods,
>>> I'll suck it up, but "mostly harmless" is not exactly a ringing
>>> endorsement.
>>>
>>> --tim
>