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

[Maurizio Cimadamore]

On Wed, 16 Nov 2022 11:03:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Yes, my comment was really on `get` - that said, I note that saying get().get() would look odd (but maybe finding some other name for `ScopedValue::get`, such as `find` might work)
>
> 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.

-------------

PR: https://git.openjdk.org/jdk/pull/10952