-
Notifications
You must be signed in to change notification settings - Fork 28
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
surprising discriminator
behavior
#239
Comments
I see now the issue is is that final protected[this] def addDiscriminator[B](
encode: Encoder[B],
value: B,
name: String,
discriminator: Option[String]
): JsonObject
|
From my perspective everything is working as expected, and your manual decoder is wrong. In circe-generic and circe-generic-extras I think it assumes if you make a case class the subclass of a sealed trait, there will 1 day be more case classes for that trait (thats usually why you do that). So in order to decode those later, you are going to need a discriminator. Now, where the discriminators are were completely determined by where you had your configuration. For the semi-auto For the semi-auto {
"innerA" : { // because the field in `WrappedB` was called `innerA`
"B" : { // Because the `InnerA` in `innerA` was of type `B` this is the discriminator. (Default circe generic behavior)
"value" : "foo",
"num" : 42
}
},
"operation" : "WrappedB" // Because Wrapped is a sealed trait it MUST have a discriminator, and `operation` was set in the configuration, so we discriminate there.
} The manual codec you list is ignoring the fact that We do have a |
Close, but feel free to reply or reopen if you see something wrong. |
I am using
circe-generic-extras
to add adiscriminator
to a simple ADT but I notice that when I manually provide aEncoder
for one of the ADT members, thediscriminator
does not encode as expected however thediscriminator
does encode as expected if Iderive
anEncoder
instance.Here is a simple example to illustrate the discrepancy:
Note the different behavior depending on which
Encoder[WrappedB]
is in scope.Also, here is a scastie with the same code as above with the versions I am currently using. Is this a bug or am I just happening to do things in an unexpected way?
Thanks in advance.
The text was updated successfully, but these errors were encountered: