Migrate to JSON3 #25
Merged
Migrate to JSON3 #25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -18,51 +16,46 @@ end | |||
| Create a type that can be parsed from JSON. | |||
| """ | |||
| macro json(def::Expr) | |||
There was a problem hiding this comment.
Would you mind adding in some comments here? Personally I haven't worked too much with macros and expressions, so a lot of this goes over my head.
Would probably make it a bit easier to maintain in the future too!
|
I assume you're waiting for JuliaData/StructTypes.jl#52 to be approved/etc. Is there somebody we can ping to get that going? This would be great to get merged in soon |
|
Anything, in particular holding this up? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #9, ref #22
I'm pretty sure that the weirdness of dateformats for GitLab is isolated to commits; I went through all the GitLab API docs and I only found the nonstandard format there. So I've not allowed for any user configuration of the formats, but we can change them on a per-type level and a per-field level too.
Due to some limitations in JSON3/StructTypes, I've also gotten rid of the
_extrasfield on all types, and any keys that come from the API that are not present in the struct will throw an error. I definitely don't want that, so I'm looking at a couple of options:ignoreextrasflag to JSON3 that makes it not throw errors for extra keys (easy, Add ignoreextras feature JuliaData/StructTypes.jl#52)KeywordArgsStructto StructTypes to facilitate implementing_extrasin the same way we did before (not so easy)