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

[Alan Bateman]

On Wed, 16 Nov 2022 11:41:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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