Hi Kotliners, A post xmas question for anyone aliv...

# announcements

[Mark Fisher]

Hi Kotliners, A post xmas question for anyone alive in this time of limbo before the new year!
I've got a generics question. I can't understand why there's an error in the following:

interface HexData
object EmptyHexData : HexData
data class Hex(val q: Int, val r: Int, val s: Int)

interface HexDataStorage<T: HexData> {
    fun addHex(hex: Hex)
    fun addHex(hex: Hex, data: T): Boolean
}

class DefaultHexDataStorage<T: HexData> : HexDataStorage<T> {
    private val storage = LinkedHashMap<Hex, T>()

    override fun addHex(hex: Hex) {
        storage[hex] = EmptyHexData // <-- ERROR
    }

    override fun addHex(hex: Hex, data: T): Boolean {
        val previous = storage.put(hex, data)
        return previous != null
    }
}

In the function addHex(hex: Hex), I cannot use "EmptyHexData", and I don't understand why. AFAIU It's a sub-type of HexData, so I thought it would comply with the requirement of being a T in this case. What's wrong, and how do I fix it?
I tried using a class too, e.g. class EmptyHexDataClass: HexData but that didn't work either.

[Giorgos Neokleous]

Do you need generics at all in your example? Seems like you can just get by without them

interface HexDataStorage {
    fun addHex(hex: Hex)
    fun addHex(hex: Hex, data: HexData): Boolean
}
class DefaultHexDataStorage : HexDataStorage {
    private val storage = LinkedHashMap<Hex, HexData>()
    override fun addHex(hex: Hex) {
        storage[hex] = EmptyHexData
    }
    override fun addHex(hex: Hex, data: HexData): Boolean {
        val previous = storage.put(hex, data)
        return previous != null
    }
}

[Yev Kanivets]

addHex(hex: Hex) takes Hex, not T, and EmptyHexData doesn’t inherit from Hex, but from HexData.

[Vampire]

@Yev Kanivets I think you misread the example

[Mark Fisher]

@Yev Kanivets that's not right here, the type is in the storage.

[Vampire]

@Mark Fisher T is HexData or a subtype of it

[Vampire]

So if you have interface MyHexData : HexData and then have a DefaultHexDataStorage<MyHexData> that would be legal

[Vampire]

But then you couldn't assign EmptyHexData as it is a HexData, but not a MyHexData

[Vampire]

That's why it says "you have EmptyHexData but T was expected"

[Mark Fisher]

@Giorgos Neokleous I did consider a non-generics version, and instead have a Maybe<T> there, but still would like to get this working without the Maybe class which I think adds noise.
@Vampire isn't EmptyHexData a subtype of HexData?

[Vampire]

So it's back to the question of Girogos, why generics at all

[Vampire]

Of course it is, but not of MyHexData as I just explained

[Vampire]

If you create a DefaultHexDataStorage<MyHexData> your map will have runtime type LinkedHashMap<Hex, MyHexData> and EmptyHexData is not a MyHexData but a sibling

[Mark Fisher]

ah, that explains it better, when considering the actual implementation, i need a full type.

[Vampire]

So again the question of Giorgos, why do you need generics at all?
Or a Maybe whatever that should be.

[Vampire]

Why wouldn't his suggestion work for you?

[Mark Fisher]

It is good enough to not use Generics, but I couldn't understand why the posted version wasn't working. You've explained that well enough now for me to understand, so thanks! 🙂

[Rob Elliot]

In terms of what you’re trying to achieve with the generic type, you’re probably better off using null to represent `EmptyHexData`:

private val storage = LinkedHashMap<Hex, T?>()
    override fun addHex(hex: Hex) {
        storage[hex] = null
    }

[Mark Fisher]

@Rob Elliot That's why I used Maybe<T>, to avoid the use of nulls:

private val storage = LinkedHashMap<Hex, Maybe<T>>()

    override fun addHex(hex: Hex) {
        storage[hex] = Maybe.empty()
    }

    override fun addHex(hex: Hex, data: T): Boolean {
        val previous = storage.put(hex, Maybe.of(data))
        return previous != null
    }

Although my current implementation doesn't need generics, so I've stripped it back to simple HexData types directly.

[Vampire]

And where is the advantage to wrap the entries instead of using a nullable type?

[Mark Fisher]

I'm averse to using nulls and nullable types.

[Youssef Shoaib [MOD]]

Using null and nullable types is idiomatic in Kotlin instead of using a maybe since the language has complete support for it. This isn't only my opinion, but also the opinion of actual fp experts like the whole Arrow team who decided to deprecate Maybe in favour of the native Kotlin nullables since the compiler tracks the nullable types and checks any calls that you try to do on them automatically (similar to how they decided to go with suspend instead of an IO wrapper since the compiler automatically tracks effects with suspend)

[Nir]

I'd agree that nullable types are idiomatic in Kotlin broadly speaking but nullables can be a bit of a pain in generic contexts

[Nir]

and in particular Map<Hex, HexData?> can be pretty annoying

[Nir]

a lot of the extension functions for Map (and MutableMap) don't do what you'd expect, and basically act as though an entry to null isn't actually in the map

[Nir]

I actually agree with the approach here, it leads to less confusing code