Common ReactionEvent interface

[MayaChen350]

I added an interface for ReactionAddEvent and ReactionRemoveEvent to remove code duplication and allow better Generics

Thing is, in one of my projects, I ended up doing a class for both of them because they're not bound by anything I could use as generic.

/** Abstraction class making using both type of events easier by sharing common properties and methods. **/
class ReactionEvent(
    private val addEvent: ReactionAddEvent? = null,
    private val removeEvent: ReactionRemoveEvent? = null
) {
    val emoji = addEvent?.emoji ?: removeEvent!!.emoji
    val guild = addEvent?.guild ?: removeEvent!!.guild
    suspend fun getMessage() = addEvent?.getMessage() ?: removeEvent!!.getMessage()
    suspend fun getUserAsMember() = addEvent?.getUserAsMember() ?: removeEvent!!.getUserAsMember()
    suspend fun getUser() = addEvent?.getUser() ?: removeEvent!!.getUser()
    suspend fun getRole(id: Snowflake) =
        addEvent?.getGuildOrNull()?.getRole(id) ?: removeEvent!!.getGuildOrNull()!!.getRole(id)
}

So basically, with that PR I'm grouping both Reaction events classes together to make things easier with an interface
Also I removed what I thought was unnecessary to keep after since both ReactionAddEvent and ReactionRemoveEvent had very similar code

Pretty simple, but efficient hopefully!

[DRSchlaubi]

For some reason I can't approve this PR for the CI, but you need to run gradlew apiDump

[DRSchlaubi]

Is it a binary incompatible change to move functions to a parent class?

[MayaChen350]

I don't think so, but just to make sure, what do you mean by that?

[DRSchlaubi]

that code compiled against a previous version will continue to work

and it is a change since the function signature changes, in this case there should be a deprecated version on the class, however that will make migrating kinda hard

/cc @lukellmann

[MayaChen350]

Actually now that I think about it, I think the signatures would change since they're linked to the interface now but still are actually linked to the class somehow? Would they be the same as before if the methods would just be overriding the interface's instead?

[DRSchlaubi]

Nah prvsly it was called ReactionAddEvent.x and now it's ReactionEvent.x

[lukellmann]

Is it a binary incompatible change to move functions to a parent class?

no, it isn't

[lukellmann]

and it is a change since the function signature changes, in this case there should be a deprecated version on the class, however that will make migrating kinda hard

the signature does not include the class the method is in

[DRSchlaubi]

Is it a binary incompatible change to move functions to a parent class?

no, it isn't

why did I belive AI

[MayaChen350]

Hi? This was kinda left out idk