-
-
Notifications
You must be signed in to change notification settings - Fork 134
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
Support multi-level sealed trait in macros #512
Conversation
02b7a33
to
e3e8eca
Compare
e3e8eca
to
9863b07
Compare
@@ -676,7 +676,7 @@ class JsMacroImpl(val c: blackbox.Context) { | |||
case jsv => $json.JsObject(Seq("_value" -> jsv)) | |||
} | |||
|
|||
jso + ($config.discriminator -> $json.JsString($config.typeNaming(${t.typeSymbol.fullName}))) | |||
$json.JsObject(Map($config.discriminator -> $json.JsString($config.typeNaming(${t.typeSymbol.fullName})))) ++ jso |
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.
If the sub-writer use the same discriminator name, let it overwrite the value with the more specific type
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 like the improvement but I think it has the potential of breaking some existing code that relies on this behavior.
Should this be released on a new major or maybe behind a setting?
For me the fix make sure the already expected behaviour, so that's not breaking. Anyway if we think about a setting, it would mean exposing a setting to keep an invalid discriminator ? |
ping |
Yeah, I think you're right. The improvement on the PR makes everything work as one would expect. If someone relies on the current (unexpected) behavior, then they can force their way out of the correct implementation by tunning the Format's. |
Considering:
For now the discriminator from the top level overwrite the one from the sub one:
See failing test