-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate bit flags #766
Generate bit flags #766
Conversation
- Cleanup generator code Co-authored-by: Lukellmann <[email protected]>
Place the companion object last to preserve the order as before and remove the duplicated comment at the top of the files.
Placed extensions under the right sections, renamed them to match the original KotlinPoet names and added all available parameters from the original functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i somehow feel like it isn't a good idea to use the same annotation for generation kord enums and flags, although they are really similar, what do you think about this?
common/build/generated/ksp/main/kotlin/dev/kord/common/entity/ButtonStyle.kt
Outdated
Show resolved
Hide resolved
common/build/generated/ksp/main/kotlin/dev/kord/common/entity/MessageFlag.kt
Outdated
Show resolved
Hide resolved
common/build/generated/ksp/main/kotlin/dev/kord/common/entity/MessageFlag.kt
Outdated
Show resolved
Hide resolved
marked this as a draft for now because i think there is still some significant work needed (e.g. convert all existing flags to be generated while mostly preserving binary compatibility) |
I thought about this for a while and came to the conclusion that you would have essentially the same annotation twice |
Co-authored-by: Lukellmann <[email protected]>
common/build/generated/ksp/main/kotlin/dev/kord/common/entity/MessageFlag.kt
Outdated
Show resolved
Hide resolved
- Always use valueName "code" for flags
- No longer use internal
4e35983
to
f6bbd68
Compare
c15894c
to
916ce0c
Compare
5cca08f
to
ef70748
Compare
ef70748
to
e1e75c4
Compare
The deprecation cycle will be done when those annotations are uncommented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this is ready now, can you take another look @DRSchlaubi?
This PR adds bit flag classes to the code generation in Kord (see #686 for the reasoning of generating boilerplate heavy parts of Kord).
It also tries to unify the API shape of all existing bit flag classes by deprecating some existing declarations and replacing them with declarations that all bit flag classes have in common. They now have this general API shape:
This means that flag classes are no longer
enum class
es. Binary compatibility was preserved as far as possible, but the fact that these classes now no longer havejava.lang.Enum
as their supertype is a binary incompatible change.This PR also
ActivityFlag.PartyPrivacyFriends
,ActivityFlag.PartyPrivacyVoiceChannel
andActivityFlag.Embedded
(these were missing before)UserFlag.System
(it was undocumented in 2021)Intent.GuildBans
toIntent.GuildModeration
(see here).copy{ /* ... */ }
would also modify the original instance for bit flags based onDiscordBitSet
minus
functions that would toggle instead of remove bits (this.value xor other.value
->this.value and other.value.inv()
)