Shouldn’t something like this be possible? ```seal...

# getting-started

[jean]

Shouldn’t something like this be possible?

sealed class DataTest {
    data class A(val value: String): DataTest()
    data class B(val value: String): DataTest()
    data class C<Type>(val value: Type): DataTest()
}

fun test(dataClass: DataTest.A) = println("A: ${dataClass.value}")
fun test(dataClass: DataTest.B) = println("B: ${dataClass.value}")
fun test(dataClass: DataTest.C<*>) = println("C: ${dataClass.value}")

fun reducer(dataClass: DataTest) = test(dataClass) // compiler complains that there is no test function with parameter DataTest

@Test
fun shouldWork() {
    reducer(DataTest.A("a"))
    reducer(DataTest.B("b"))
    reducer(DataTest.C(0))
}

Since the sealed class defines exactly the number of child for DataTest couldn’t the compiler check that there is a test function for each child? Instead of implementing a whole visitor pattern

[Sam]

Function overloads are resolved statically (at compile time).

[ephemient]

you could write

fun reducer(dataClass: DataClass) = when (dataClass) {
    is A -> test(dataClass)
    is B -> test(dataClass)
    is C -> test(dataClass)
}

but yeah, as Sam says, the fact that the three functions have the same name is irrelevant

[jean]

I was trying to avoid the when 🤷🏻

[Sam]

The ability to use when is kind of the whole point of a sealed type.

[Sam]

I resisted at first too 😄 my Java background made me think it was a bad idea. But I’ve softened to it. In practice it’s much cleaner and easier to follow than a visitor pattern.

[jean]

I completely agree and use when quite often, it was more of a theoretical wonder

[CLOVIS]

It's important for readability that a single place in code calls a single function, and it doesn't depend on the value of the argument. The exception of course is inheritance, but this is very well delimited (it can only happen based on the receiver, functions must be marked abstract or open to allow it, etc)

[Sam]

I mean, multiple dispatch is a thing, Kotlin just doesn’t have it…

[jean]

I was wondering this because C looses the type due to erasure, so I can’t get a when statement for C with this

is C<String> -> ...
is C<Int> -> ...

[CLOVIS]

Kotlin has type erasure too, but that's only for type parameters. A sealed class is a proper inheritance hierarchy, there is no type erasure there

[ephemient]

`as`/`is` can only check the erased type (except for Array<>, for somewhat historical Java reasons)