Skip to content
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

Open
theduke opened this issue Jul 15, 2022 · 3 comments
Open

Union / Sum Datatype #126

theduke opened this issue Jul 15, 2022 · 3 comments

Comments

@theduke
Copy link

theduke commented Jul 15, 2022

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:

  • allow the datatype property to be an array of possible types
  • add an additional property for the Property class: somehting like alternativeDataTypes
  • require defining a custom datatype for each union.
    There could be a UnionType class which has a datatypes 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 lot

Non of these is really ideal.

Curios about alternative thoughts here.

@theduke
Copy link
Author

theduke commented Jul 15, 2022

Ah, I see there is some overlap here with the allows-only concept in #27 .

@theduke
Copy link
Author

theduke commented Jul 15, 2022

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.

@joepio
Copy link
Member

joepio commented Jul 16, 2022

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 enum values, which can definitely be used as Unions.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants