On Wed, 16 Nov 2022 12:01:58 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> IMHO there are ways to have the cake and eat it too. That is, we could have
>> a couple of overloads:
>>
>>
>> T get() { ... } // throws NSME if not found
>> Optional<T> find() // returns empty optional if not found
>>
>>
>> Then, for simple use cases, code will stay the same as today. But, if users
>> want to deal with optionality explicitly, they can call `find` and then call
>> `orElse`, `map` or whatever they like.
>
> We expect isBound() will be used a lot and I think that is clearer (and
> cheaper) than find().isEmpty().
>
> Time will tell on orElse/orElseThrow and whether they should be replaced with
> an Optional view. That is, I think your comments mostly apply to those two
> methods rather than get/isBound.
Note that `isBound` can also be explained as just a shorcut for
`find().isEmpty()`. That is, I'm not really suggesting to drop sugary methods
from the API. But by exposing the optional nature of the result, the API might
end up being more composable.
But, as you said, we don't have to decide now.
-------------
PR: https://git.openjdk.org/jdk/pull/10952
