kordlib
Common ReactionEvent interface
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!
For some reason I can't approve this PR for the CI, but you need to run gradlew apiDump
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
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?
Nah prvsly it was called ReactionAddEvent.x and now it's ReactionEvent.x
Is it a binary incompatible change to move functions to a parent class?
no, it isn't
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
Is it a binary incompatible change to move functions to a parent class?
no, it isn't
why did I belive AI
I can see that this repo is able to make PRs rot for 3 years but I don't know
My PR didn't seem like such a breaking change. It's almost ridiculous that it has been ignored for that long
If this has been fixed, or if this PR has become useless/impossible to merge now, I guess this PR can at least be closed