-
Notifications
You must be signed in to change notification settings - Fork 4
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
Support Union definition processing #63
Support Union definition processing #63
Conversation
@snosenzo is this ready for review or still a draft? I guess it's only a draft because it was stacked on the other PR? |
return this.astNode.name; | ||
} | ||
|
||
get isComplex(): boolean { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe an unpopular opinion but I don't like this "isComplex" attribute name. It's something we inherited from the old days of webviz ROS message support. The name doesn't seem to do a great job of describing what it means (since we don't really use the word "complex" elsewhere in our code so it's not really a well-known term). Maybe someday we can come up with a better name or a different way of representing this information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I definitely agree. It's really not evident how this is going to be used or what it means. Right now I'm just using it to signify that these types are not resolved like non-complex types and don't have direct, simple serializers. I'm using the aggregatedKind
attribute (taken from the IDL/DDS spec) to augment this, but maybe there's a variable name that's better for MessageDefinition
? i am trying to keep this mostly compliant with MessageDefinition
for now. Food for thought for the future though
get cases(): Case[] { | ||
return this.astNode.cases.map((def) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the reasoning for implementing these as get
ters vs. computing them once and storing them as members?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted instances of these classes to also take the shape of their final resolved type so that when accessing them you don't have to worry about resolving. As for why I'm not computing and storing them once, I did want to memoize these with a decorator to reduce repetition, but the last PR ended up being too big so I'll do it in another PR.
}, | ||
}, | ||
{ | ||
predicates: [1], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When is predicates.length != 1
? Let's get some test cases covering that too.
7329e5c
to
a1534dc
Compare
Support for resolving references in Union cases, switchType, or defaultCase.
FG-4329