Additional extension methods for collections

[Quillraven]

@czyzby are we missing some common map utility functions like getOrPut? Or is it part of a different package? I am using ktx-collections.

If it is missing, shall we add something like

inline fun <K, V> ObjectMap<K, V>.getOrPut(key: K, defaultValue: () -> V): V {
    return if (this.containsKey(key)) {
        this[key]
    } else {
        val newValue = defaultValue()
        this[key] = newValue
        return newValue
    }
}

for all map types? And maybe other typical common utility functions?

Also, is getOrPut the same as computeIfAbsent ?

[czyzby]

Yeah, utilities like that are not available in LibGDX, and since they don't implement any of the standard collection interfaces, Kotlin stdlib doesn't help either. My biggest issue with adding utilities like this is that you have to duplicate code for pretty much all of the collections, since they don't use any custom interfaces or inheritance either.

I originally wanted to write a code generator for that, see #275. You'd basically list all of the LibGDX collections with some additional parameters (e.g. collection type, supported elements, aliases), and the utilities would be generated along with tests. However, I didn't have time to work on this so far - besides, most of the LibGDX collections are very rarely used, so I'm not sure if this project would be that important.

Anyway, If you want to add a few utilities to the core map collections or try to tackle #275, I'll be happy to review the changes. If you don't have the time, I'd appreciate it if you listed the utility methods that you'd like to see and I will set up a separate issue for that.

[Quillraven]

Wouldn't it already help if e.g. all map implementations use a common interface like GdxMap? Can be a very simple one that only contains get and put which I hope all implementations have (maybe also contains).

That way we could already add extensions for all maps, no?

edit: raised now an issue: libgdx/libgdx#6406
Let's see what the experts are saying ;)

[czyzby]

In general - yes, but there are some exceptions that we might want to handle differently. For example, there are maps for primitive values like IntIntMap, where a generic extension method would just box the primitives. This isn't that bad, especially on desktop, but I'm guessing LibGDX devs had a reason to avoid this.

Same goes for a common interface - methods like put or get with boxed values would have to be deprecated in favour of custom methods with primitives to avoid excessive GC, which is the whole point behind LibGDX collections.

[Quillraven]

Seems like this is not gonna happen in the near future. There are discussions even to not upgrade to Java 7 to stay compatible with Java 6 users.

I personally think it is not the correct decision because people are used to "comfort" features and not having them available in a "modern" library is not ideal. However, I accept and understand their reasoning and I am for sure not an expert when it comes to the compatibility topic on different devices.

Anyway, currently I am only missing getOrPut but I am working on some features this weekend and might find other missing useful functions.

I will make a PR in any case. Shall we maybe wait for that before releasing an official 1.9.14 ktx version?

[czyzby]

Sure, I can wait with the release a bit. Take your time.

[czyzby]

New extensions added in #345.