brian.goetz at oracle.com
Fri Dec 7 15:37:43 UTC 2018
> I really like Tagir's suggestion about (2): Optional<E> findValue(String
Yes, it has an attractive cost-benefit.
> But this leads me to a question regarding Map... Have you ever considered
> adding the equivalent default method to the Map interface?
Why yes, yes we have ;)
The tl;dr: version is: we're not touching this until Valhalla.
First, note that Map::get uses `null` as a sentinel for "not found".
What does this do when we have a `Map<String,int>`? Box? Yuck.
`Map::get` is called way too often to tolerate this kind of boxing.
Similarly, if we were to add this method now, we'd have the same
problem; Optional is a heavyweight object box. Again, Map::get is
called way too often to tolerate this. (When Optional is a value,
So, how would we design fetching from a Map if we knew there were some
types that were non-nullable? Well, lots of options, each with pros and
- Like what we have today, but which returns a nullable type: `V?
- A version that takes a user-provided sentinel to express "not
found", such as `V get(K key, V sentinel)`
- A version that takes a lambda: `boolean get(K key, Consumer<V>
- An optional-bearing version, such as `Optional<V> get(K key)`
- A pattern match: `if m matches Map.withMapping(k, var v)`
The design space here is pretty big. The requirements on the language
(nullable types? pattern matching? value optionals?) range all over
the map too. For each of them, they are really convenient for some use
cases but really inconvenient for others. Should we require Map
implementations to implement all of them?
As you can see, this is far from a "why not just..." sort of question.
More information about the core-libs-dev