On Wed, 16 Nov 2022 11:41:49 GMT, Maurizio Cimadamore <[email protected]>
wrote:
>> It certainly would look odd. This API is, by design, as lightweight as it
>> possibly can be, both from an implementation and a user's point of view.
>> It's also intended to be as close as possible to an "invisible" parameter
>> passed to all callees. From that point of view, `get()` is a wart.
>> `get().get()` is just...
>
> 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.
-------------
PR: https://git.openjdk.org/jdk/pull/10952
