Skip to content
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

improve the json layer #44

Open
cottoncammy opened this issue Apr 18, 2023 · 0 comments
Open

improve the json layer #44

cottoncammy opened this issue Apr 18, 2023 · 0 comments

Comments

@cottoncammy
Copy link
Owner

cottoncammy commented Apr 18, 2023

big changes i want to do before releasing 1.0.0 version. i want to support records for objects returned by discord to improve the dev experience for the kotlin module (currently, object getters don't have standard getter names, so kotlin property syntax isn't available for them). this means i'd probably have to upgrade the build to at least java 17.

additionally, i want to try out using jackson polymorphism for message components and possibly application command options.

also need to try to improve the java builder syntax for creating / bulk overwriting application commands as it's very clunky compared to the kotlin dsl.

i also need to improve the experience for creating and parsing application command interaction data option and application command option choice values, and for parsing audit log change values (as they all rely on JsonNode). i'll likely have to wrap some of these into higher-level objects to improve usability or somehow use jackson polymorphism to get rid of the JsonNode requirement.

the java builders could also benefit from some custom with-er methods to improve the syntax but i'd have to migrate away from immutables or further mess with the fork to accomplish this.

some of the serializable json objects, like the MessageEmbed sent in message requests, accept some optional values that can't actually be serialized in requests and are only sent on responses. i can either create a different type and users would have to deal with converting them, or just leave it as is (the latter of which i'm leaning towards).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant