``` abstract class A() class B(): A() class C(): A...

# announcements

[Rob]

abstract class A()
class B(): A()
class C(): A()

fun foo(b: B)
fun foo(c: C)

If I have something like this, a base class with subclasses and overloaded functions, what is the "best" way to call it IF they are stored in a variable of type A?

class Something(val member: A)

val v = Something(B())

foo(v.member) // How to get this to call the right foo

[Dico]

foo(a as B)

[Dico]

if (a is B) {
    foo(a)
}

[natpryce]

You want polymorphism on the concrete subclass of A. So make foo an abstract method in A, with implementations in B and C

[natpryce]

you can make foo(a) call the method, if you don’t want the change to impact existing client code

[Rob]

that seems "better" than having a big when switch

[Rob]

however that forces the functions to be public

[natpryce]

Or…

[natpryce]

Make A a sealed class

[natpryce]

Then foo can use an exhaustive when expression to switch on the subtype of A. That way the compiler tells you if foo no longer handles all subclasses of A if you add a new one

[Dico]

I though your foo is a top level function

[Rob]

This results in something like:

when (v) {
is B -> foo(v)
is C -> foo(v)
is D -> foo(v)
}

is there no better way?

[Dico]

If foo are top level functions no

[natpryce]

It depends on your trade-offs

[Dico]

However if you can modify the classes, you could use a visitor pattern

[Dico]

Or just delegate the calls directly from an abstract function

[natpryce]

In kotlin you either have polymorphic methods or algebraic data types (sealed classes in Kotlin syntax). Polymorphic methods make it easier to add new subtypes, but harder to add new operations. Sealed classes make it easier to add new operations but harder to add new subtypes.

[natpryce]

So one has to choose between them depending on what is most likely to vary in your system.

[Rob]

Alright thanks

[Dico]

Sealed classes are just abstract classes

[natpryce]

(This dichotomy is called the Expression Problem in computer science literature. Some languages have mechanisms to address this, such as type classes, but Kotlin doesn’t right now and maybe never will)

[Dico]

Algebraic data types?

[Dico]

I dont believe that's a thing in kotlin

[Dico]

And polymorphic methods- are you talking about virtual functions?

[Dico]

Sorry I'm just confused

[natpryce]

Sealed classes are Kotlin’s mechanism for defining algebraic data types. “Algebraic data type” is the concept. Sealed classes is Kotlin’s syntax for that.

[natpryce]

Yes. Kotlin doesn’t have the concept of “virtual functions” like, say, C++ does. Instead if has methods that can be “abstract” or “open”. In both cases (C++ virtual functions, Kotlin’s open methods), the method call is polymorphic — it can do different things if called on different concrete types.

[Dico]

open and virtual functions are intervhangeavle terms

[Dico]

And I think it would be more accurate to say that algebraic data types could be an application of sealed classes right?

[natpryce]

Or maybe that a sealed class hierarchy forms an algebraic data type.

[Dico]

I dont want to dive into a discussion