Currently, the only union types supported are Union[T1, T2, ...., Tn]
that cannot be named. For example, it is not possible to distinguish Union[T1, Union[T2, T3]]
from Union[Union[T1, T2], T3]
. However, in most real-world scenarios, sum types are named and these names come in handy when tagging serialized sum types.
A prevalent example of named sum-types are class hierarchies.
For example, when decoding JSON, an unnamed union can be as unrestricted as a priority-based decoder but a named union has some structure to it such as being a JSON object and using the name of the super class as a field inside the JSON to show the type that is being decoded. In the absence of named unions, such a field would either have to have a very generic name (such as tag
) or it would have to be manually generated.
So, three main asks:
- Separate the concept of named unions from unnamed unions.
- Implement class hierarchy auto extraction in extractor.
- Implement both named and unnamed JSON decoding/encoding.
One additional ask:
Decoding/encoding JSON for named unions should allow both the following:
{
"SuperClassName": "SubClassName",
... // sub-class fields
}
and
{
"type": "SubClassName",
"value": sub_class_encoding
}