When I use sealed classes, I end up writing lots of functions like:

fun doSomethingWith(arg : SealedBaseClass, otherArg: Int) = when(arg) {
    is SubclassA -> doSomethingWith(arg, otherArg)
    is SubclassB -> doSomethingWith(arg, otherArg)
 }

fun doSomethingWith(arg : SubclassA, otherArg: Int) = ... 
fun doSomethingWith(arg : SubclassB, otherArg: Int) = ...

What do people think of the idea of a sealed function, where the compiler generates the when boilerplate for you? E.g.

sealed fun doSomethingWith(arg : SealedBaseClass, otherArg: Int)

fun doSomethingWith(arg : SubclassA, otherArg: Int) = ... 
fun doSomethingWith(arg : SubclassB, otherArg: Int) = ...

I’m imagining the same rules would apply as for sealed classes: all implementations of the sealed function have to be in the same source file. And the compiler would check them for exhaustiveness.

You may want to use inheritance instead. Say the

doSomething

was part of class

MyClass

, then you could add an abstract method

abstract fun MyClass.doSomething(): Result

to the SealedBaseClass.

Polymorphic methods and sealed classes have different use cases. Polymorphic methods are useful when the set of types varies more frequently than the set of operations on those types. Sealed classes are useful when the set of operations varies more frequently than the set of types they apply to. This is a suggestion about sealed classes.

I think

when

gives you more power since you can group multiple classes together and have an else. With such a sealed function that would be difficult. So if you’d have a sealed function like that and later subclasses are added or requirements change you might find yourself changing it to a

when

for the extra functionality. So even though I think it’s a nice idea I think in reality it would come with some potential downsides and it doesn’t really add something you cannot already do.

Hey! Maybe this is the wrong thread to ask, but a doubt came to my mind... What do you think about sealed classes and the visitor pattern? Should we replace the use of the visitor pattern with the use of the when clause?

Personally — Yes. In Kotlin I only use the visitor pattern if a Java library requires it

Just because you are using sealed classes, doesn't mean you cannot have an interface in the sealed class that all children implement

Because sealed classes are intended for when operations are implemented separately from the class.

okay, fair enough, so you're talking about a case where the person implementing doSomethingWith doesn't own the class

Sealed classes are a language mechanism for what Java has to do with the Visitor pattern

that's not exactly 1 to 1

the

when

boilerplate is still there, now the doSomethingWith is a big function, and you have to do a dispatch on type even when you have a subclass of the sealed class.

it's not boilerplate, whether you write:

fun doSomethingWith(arg : SealedBaseClass, otherArg: Int) = when(arg) {
    is SubclassA -> // snippet foo
    is SubclassB -> // snippet bar
 }

Or

fun doSomethingWith(arg : SubclassA, otherArg: Int) { // snippet foo }
fun doSomethingWith(arg : SubclassB, otherArg: Int) { // snippet bar}

They are exactly equivalent. In both pieces of code, you mention each subclass once