Kotlin: Use a lambda in place of a functional interface?
Solution 1
A lot of nice things has happened to Kotlin since @andrey-breslav posted the answer. He mentions:
It is that Kotlin only does SAM-conversion for functions defined in Java. Since Events.handler is defined in Kotlin, SAM-conversions do not apply to it.
Well, that's no longer the case for Kotlin 1.4+. It can use SAM-conversion for Kotlin functions if you mark an interface as a "functional" interface:
// notice the "fun" keyword
fun interface EventHandler<T> {
fun handle(event: T)
}
You can read the YouTrack ticket here: https://youtrack.jetbrains.com/issue/KT-7770. There's also an explanation why Kotlin needs a marker for such interfaces unlike Java (@FunctionalInterface
is only informational and has no effect on the compiler).
Solution 2
Assuming below that you really need EventHandler
as a separate interface (e.g. for Java interop). If you don't, you can simply use a type alias (since Kotlin 1.1):
typealias EventHandler<T> = (T) -> Unit
In this case a simple lambda will work right away.
But if you don't want to use a type alias, the issue still stands. It is that Kotlin only does SAM-conversion for functions defined in Java. Since Events.handler
is defined in Kotlin, SAM-conversions do not apply to it.
To support this syntax:
Events.handler(Handshake::class, EventHandler<Handshake> { println(it.sent) })
You can define a function named EventHandler
:
fun <T> EventHandler(handler: (T) -> Unit): EventHandler<T>
= object : EventHandler<T> {
override fun handle(event: T) = handler(event)
}
To support this syntax:
Events.handler(Handshake::class, { println(it.sent) })
or this:
Events.handler(Handshake::class) { println(it.sent) }
You need to overload the handler
function to take a function instead of EventHandler
:
fun <T> Events.handler(eventType: Class<T>, handler: (T) -> Unit) = EventHandler(handler)

Jire
Updated on June 10, 2020Comments
-
Jire over 2 years
In Java we can do this
Events.handler(Handshake.class, hs -> out.println(hs));
In Kotlin however I am trying to replicate the behavior to replace this:
Events.handler(Handshake::class, object : EventHandler<Handshake> { override fun handle(event: Handshake) { println(event.sent) } })
With a more convenient:
Events.handler(Handshake::class, EventHandler<Handshake> { println(it.sent) })
For some reason in reference to
EventHandler
:More preferably however I'd like to use something even shorter like this:
Events.handler(Handshake::class, { println(it.sent) })
Or use the advertised feature to use the method like this:
Events.handler(Handshake::class) { println(it.sent) }
This is my
Events
object:import java.util.* import kotlin.reflect.KClass object Events { private val map = HashMap<Class<*>, Set<EventHandler<*>>>() fun <T : Any> handler(eventType: KClass<T>, handler: EventHandler<T>) { handler(eventType.java, handler) } fun <T> handler(eventType: Class<T>, handler: EventHandler<T>) = handlers(eventType).add(handler) fun post(event: Any) = handlers(event.javaClass).forEach { it.handle(event) } operator fun plus(event: Any) = post(event) private fun <T> handlers(eventType: Class<T>): HashSet<EventHandler<T>> { var set = map[eventType] if (set == null) { set = HashSet<EventHandler<*>>() map.put(eventType, set) } return set as HashSet<EventHandler<T>> } }
And my
EventHandler
interface:@FunctionalInterface interface EventHandler<T> { fun handle(event: T) }
-
Jire about 7 yearsWith a little modification I got this to work for my case. Resulting code: pastebin.com/tsLfFxnq thanks!
-
Jire about 7 yearsAlso I was able to get it to work with just
KClass
which can be viewed here: pastebin.com/mEWhA5yc -
mhshams about 7 years@andrey, Do we have above feature (using function where ever SAM is required) in Kotlin now?
-
Andrey Breslav about 7 years@mhshams nothing has changed since a month ago
-
gvlasov about 7 years@AndreyBreslav Nice to hear that type aliases are going to be supported. Is there a publicly available early design document for them? Couldn't find anything like that at github.com/JetBrains/kotlin-spec
-
Andrey Breslav about 7 years@Suseika no, there's not enough design work done to publish anything
-
Mibac over 5 years@AndreyBreslav now that type aliases are out could you update your answer please?
-
Leonid Ustenko over 2 yearsThat's a pity... Seems it is much easier to write a functional interface in Java. Writing an extra extension function for every interface is not what we expect from Kotlin, @AndreyBreslav
-
iboalali almost 2 yearsThis should be now the accepted answer for kotlin 1.4+