Nice! If you want something really powerful I’d co...
# arrow
p
Nice! If you want something really powerful I’d consider supporting unions/sealed classes
s
Great idea. I'll add that for 1.1
How do you see that working? Defining a field as the sealed class supertype, and then marshalling to one of the sealed instances? But which one to pick, look at the fields available?
p
It’s implementation-dependent, let me show you JSON
type my_sealed = Left of int | Right of string type bla = { a: my_sealed }
Copy code
"bla": {
  "a" : {
    "left" : 1
  }
}
Copy code
"bla": {
  "a" : {
    "right" : "2"
  }
}
s
so lookup the type based on the field name
In avro4s what I do is check which fields are defined, and find the sealed type that matches it
although that wouldn’t work if you have two types with the same field names
p
yes, so the validation is just seeing that there’s only one field, and the field name is one of the union
you shouldn’t
in most languages it isn’t possible to have the same name for a variant
s
I mean, if you did Left(a:String) and Right(a:String) then the presence of a field “a” isn’t enough to determine which to pick
p
and the values of a variant aren’t types themselves
yeah, that’s a frequent design mistake
the “dependent type”
happened in FlowJS a lot
s
So I guess the only way to do it is to have a nested block that informs the type
or in yaml, you could ahve another field like _type as a sibling
p
that’s the tag, it makes validating harder AFAIK
Copy code
"bla": {
  "a" : {
     "type": "right",
    "content" : "2"
  }
}
Copy code
"bla": {
  "a" : {
     "type": "left",
    "inside" : 2
  }
}
problem here: you have to parse the value, see the tag, then reparse/revalidate the contents
whereas with the other one you can directly access the deserializer based off the field
because each field corresponds to a monomorphic deserializer
same for serialization
s
yes agreed, good