RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6]

[Maurizio Cimadamore]

On Wed, 16 Nov 2022 12:01:58 GMT, Alan Bateman <alanb at 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