-
Notifications
You must be signed in to change notification settings - Fork 7
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
Union / Sum Datatype #126
Comments
Ah, I see there is some overlap here with the |
Ah, an additional idea - which is actually kinda-sorta what I implemented in factordb: Allow datatype to be a nested resource , although constrained to class types that refine existing datatypes with constraints. |
The Union datatype can be useful, but it introduces a cost for data consumers: they will now need to perform type checking. In programming languages like Rust, a Union type therefore does not exist by design. However, they do have In atomic data, we do have enums, but these function more like JS enums (a list of options that do not contain values) instead of rust enums (a list of options that may contain any type of other value). So I agree that currently, Atomic Data lacks a way to properly express something like Rust Enums or TS Unions. Can you perhaps come up with a concrete real world example of something that you can't model right now with Atomic Data? |
Values can often be one of several datatypes (like string or int, class A or class B, ...).
There should be a way to model unions (anonymous or tagged).
Describing this in the schema is a bit tricky though, since the datatype property is just a single value.
Options:
datatype
property to be an array of possible typesProperty
class: somehting likealternativeDataTypes
There could be a
UnionType
class which has adatatypes
property, and custom union datatypes specify "isA: "Union". That's rather awkward though, since you could end up with
StringOrInt` etc datatypes , which pollute the readability of a schema quite a bit, and more importantly might be duplicated a lotNon of these is really ideal.
Curios about alternative thoughts here.
The text was updated successfully, but these errors were encountered: