You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our language context we have dynamic enum-like types. For example, a query might be:
person.status == Status.Married
The enum type Status acts like how we typically understand enum types - it is defined with a set of options. For example, Status.Married or Status.Single would be the defined values.
I'm unsure exactly how to define this with the custom type provider. I've achieved a working solution by defining the enum type as a constant object type and its values as opaque types.
Could this be considered a reasonable approach?
We define all our types dynamically at runtime (and not using Go structs or proto definitions). The below Gist very simply illustrates how I have achieved this:
the issue returned on an invalid expression person.status == Status.wrong is undefined field 'wrong' but enums don't really have fields.
the issue returned on an invalid expression person.status == Status is found no matching overload for '_==_' applied to '(Status, StatusEnumDefinition)' whereas I might prefer something like value expected for Status
types.NewNullableType() doesn't seem to let define nullable fields on opaque types
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In our language context we have dynamic enum-like types. For example, a query might be:
The enum type
Status
acts like how we typically understand enum types - it is defined with a set of options. For example,Status.Married
orStatus.Single
would be the defined values.I'm unsure exactly how to define this with the custom type provider. I've achieved a working solution by defining the enum type as a constant object type and its values as opaque types.
Could this be considered a reasonable approach?
We define all our types dynamically at runtime (and not using Go structs or proto definitions). The below Gist very simply illustrates how I have achieved this:
https://gist.github.com/davenewza/81ebf3f30b0fde94419d9ba090327a5c
What isn't so great about this approach is:
person.status == Status.wrong
isundefined field 'wrong'
but enums don't really have fields.person.status == Status
isfound no matching overload for '_==_' applied to '(Status, StatusEnumDefinition)'
whereas I might prefer something likevalue expected for Status
types.NewNullableType()
doesn't seem to let define nullable fields on opaque typesBeta Was this translation helpful? Give feedback.
All reactions