Map enhancement

[Brian Goetz]

This was considered and rejected by the JSR-335 EG.  In part, it made many EG members uncomfortable because a (mutable) map is not a function, so using inheritance to reflect this is just wrong.  

The easy convertibility of the bound method reference map::get was the final nail in the coffin for this idea; it is so easy to convert it if you want, that it was not worth justifying any degree of mismatch for the sake of convenience.  

(Some) maps in Scala are immutable; you could make a stronger argument that a Map is-a Function in that case, but we’re not in that case.  


On Jun 6, 2015, at 4:55 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:

> May I ask what tangible value would be in that? As far as I understand with
> lambda syntax whenever you have
> 
>    Map<K, V> m
> 
> and you want to use it in some context as a
> 
>    Function<? super K, ? extends V> f
> 
> you can simply write
> 
>    f = m::get
> 
> so syntactical overhead is minimal.
> 
> P.S. Let me point out that a map could be also seen as a collection of its
> entries, a predicate for its keys and values
> 
>    Predicate<? super K> p1 = m::containsKey
>    Predicate<? super V> p2 = m::containsValue
> 
> a bi-consumer for (k, v)
> 
>    BiConsumer<? extends K, ? extends V> c1 = m::put;
> 
> or a bi-function (though with side-effects)
> 
>    BiFunction<? super K, ? extends V, ? super V> f1 = m::put;
> ...
> 
> When we go down to this level of fundamental abstractions, everything could be
> seen almost as everything else :)
> 
>> On 6 Jun 2015, at 20:30, Frederic Gendebien <frederic.gendebien at gmail.com> wrote:
>> 
>> Dears,
>> 
>> I think it would be great to modify the Map<F, T> so it implements Function<F, T> as it is done in Scala. In fact, Mathematically, a map is function who takes an input parameter of type F and gives back a value of type T.
>> 
>> Kind regards,
>> 
>> Frederic Gendebien.
>