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.

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
    }
}

addHex(hex: Hex)

takes

Hex

, not

T

, and

EmptyHexData

doesn’t inherit from

Hex

, but from

HexData

.

@Yev Kanivets I think you misread the example

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

@Mark Fisher

T

is

HexData

or a subtype of it

@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?

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

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

So again the question of Giorgos, why do you need generics at all? Or a

Maybe

whatever that should be.

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! 🙂

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
    }

@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.

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

I'm averse to using nulls and nullable types.

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)

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