Unmodifiable collections and maps don't allow upcasting of type parameters

[ski...@gmail.com]

Hi there,

Big fan of fastutil! Thanks for all the work you put into it, Sebastiano, and other volunteers.

Today I noticed a frustrating gap between the jdk collections and fastutil collections regarding the "unmodifiable" methods.

In the jdk methods, you can take a Collection<? extends T> and get back a Collection<T> -- with a super type for the parameter -- by wrapping it in Collections.unmodifiableCollection [link]:

    public static <T> Collection<T> unmodifiableCollection​(Collection<? extends T> c)

Likewise for maps, with similar upcasting on the key types as well (except in the case of SortedMaps) [link]:

    public static <K,​V> Map<K,​V> unmodifiableMap​(Map<? extends K,​? extends V> m)

This is generally safe to do because the resulting unmodifiable thing cannot be mutated by, say, adding a String into a Collection<Animal> simply by wrapping the latter in unmodifiableCollection to get a Collection<Object> instead.

But in the case of fastutil, the corresponding "unmodifiable" methods don't support any such changing of the generic types. For example, in Int2ObjectSortedMaps [link]:

    public static <V> Int2ObjectSortedMap<V> unmodifiable​(Int2ObjectSortedMap<V> m)

Is there some limitation to the implementation that would preclude this relaxing of the types for unmodifiable collections? Or is it just not something that's been addressed before?

Best,

Scott

[Sebastiano Vigna]

> On 17 Mar 2021, at 22:16, ski...@gmail.com <ski...@gmail.com> wrote:
> Is there some limitation to the implementation that would preclude this relaxing of the types for unmodifiable collections? Or is it just not something that's been addressed before?

Well, I think simply I didn't know. :) Thank you for making me notice this... if you have a look at my last commit (ecb3b9c) it should be the right thing. I'm not entirely sure of all the type casts, but I borrowed them from the JDK.

Incidentally, I noticed doing this that my unmodifiable wrappers from maps do not shield changes obtained with Entry.setValue(). That is work for the future...

If you send me your name, I'll add a thanks in the CHANGES.

Ciao,

seba

PS: For this kind of things, Github issues are the preferred mean of interaction, as other developers can chime in and have their say.

[Scott Kilpatrick]

Commit looks great. Thanks for the quick turnaround! And my name is Scott Kilpatrick. :-)

--
You received this message because you are subscribed to a topic in the Google Groups "fastutil" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fastutil/q_ilvXKhKbg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fastutil+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fastutil/479286e6-fa46-45b5-b104-12516becb9e2n%40googlegroups.com.