Hi all, a high level question. I am test driving Elm and like it. However, it got me thinking of something Kotlin related. If I was to create some sort of VDOM consisting of simple data classes and compare those that would just work fine. However, when I'd include events, using some sort of 'onClick' anonymous function, the diffing will always cause to assert that the anonymous functions are different, even when they are structurally the same. As I believe Elm doesn't have this problem (because of a complete different language and compiler). Example:

data class Node(val name: String, val onClick: () -> Unit)

fun main() {
    val a = Node("Foo") { println("Foo") }
    val b = Node("Foo") { println("Foo") }
    println(a == b) // prints "false"
}

Is there a way to obtain something similar?

#compose takes a different approach of skipping execution when inputs are unchanged instead of a vdom which sidesteps some of this class of issues. It also performs some memoization of lambdas created in

@Composable

functions as a related optimization

Also you can simply move the onClick out of the primary constructor so that the data class doesn't consider it part of the data. This should work:

data class Node private constructor(val name: String) {
    lateinit var onClick: () -> Unit
    	private set
    constructor(name: String, onClick: () -> Unit): this(name) {
        this.onClick = onClick
    }
}

fun main() {
    val a = Node("Foo") { println("Foo") }
    val b = Node("Foo") { println("Foo") }
    println(a == b) // prints "true"
}

Also, I believe react-kotlin ran into that problem, and the workaround was to declare your functions as vals like this:

data class Node(val name: String, val onClick: () -> Unit)

val printFoo = { println("Foo") }

fun main() {
    val a = Node("Foo", printFoo)
    val b = Node("Foo", printFoo)
    println(a == b) // prints "true"
}

not considering the callback to be part of the data tends to be a big problem here since it means if the lambda capture changes, the nodes will compare equal and not be updated with the new lambda capture

if you want to do elm-like things on the JVM, mobius might be an option. there, we chose not to pass functions around, but rather value objects. there are tradeoffs, ofc, in particular, using value objects rather than defining both when the event should be triggered, and what the event means (what action it should trigger) in one place is more verbose, but provides better separation of concerns. See https://github.com/spotify/mobius/wiki/Concepts

Sorry for the late reply! Thanks a lot for all your input, some nice answers. I