Generic interaction create events

[lukellmann]

Changes

• make InteractionCreateEvent generic over its interaction property
• change superinterface of GuildComponentInteractionCreateEvent and GlobalComponentInteractionCreateEvent

before

Event <- InteractionCreateEvent <- [Guild|Global]ComponentInteractionCreateEvent

after

Event <- InteractionCreateEvent <- ComponentInteractionCreateEvent <- [Guild|Global]ComponentInteractionCreateEvent

Example where you can benefit from a generic interaction property

Without generic interaction

suspend inline fun <E : InteractionCreateEvent> E.foo(ack: E.() -> InteractionResponseBehavior) {
    val response = this.ack()
    response.edit { /* ... */ }
}

suspend fun ButtonInteractionCreateEvent.bar() {
    // you have to obtain `interaction` here to access all its methods
    foo { interaction.acknowledgePublicDeferredMessageUpdate() }
}

suspend fun ChatInputCommandInteractionCreateEvent.baz() {
    foo { interaction.acknowledgePublic() }
}

With generic interaction

suspend inline fun <I : Interaction, E : InteractionCreateEvent<I>> E.foo(ack: I.() -> InteractionResponseBehavior) {
    val response = interaction.ack()
    response.edit { /* ... */ }
}

suspend fun ButtonInteractionCreateEvent<*>.bar() {
    // access methods of interaction directly, its type is know through generics
    foo { acknowledgePublicDeferredMessageUpdate() }
}

suspend fun ChatInputCommandInteractionCreateEvent<*>.baz() {
    foo { acknowledgePublic() }
}

[HopeBaron]

I don't get it; you are calling the function in their class
For example

suspend fun ChatInputCommandInteractionCreateEvent<*>.baz() {
    foo { acknowledgePublic() }
}

You already assume it's type is ChatInputCommandInteraction at the very least

[lukellmann]

I don't get it; you are calling the function in their class
For example

suspend fun ChatInputCommandInteractionCreateEvent<*>.baz() {
    foo { acknowledgePublic() }
}

You already assume it's type is ChatInputCommandInteraction at the very least

Yes, but acknowledgePublic() is still a method on the interaction of the event, not the event itself. If it isn't generic, there would be no way to have the correct interaction type directly in scope of the lambda in foo().

[lukellmann]

waiting for #531

[lukellmann]

After thinking about this for a while I'm not sure if this change is actually a good idea. The major downside comes with Kotlin's syntax for generic is checks. If you want to listen for an event that isn't a concrete class (e.g. ButtonInteractionCreateEvent), you would have to add a star projection:

kord.on<ButtonInteractionCreateEvent<*>> {
    // ...
}

This does not only look somewhat strange but will also break the compilation for a lot of (if not all) projects using kord.

Combined with the rather small benefits of this approach (see PR description) it's probably not worth the hassle.

[lukellmann]

I'm closing this for now, we can reopen it if needed.