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

Support Union definition processing #63

Conversation

snosenzo
Copy link
Collaborator

Support for resolving references in Union cases, switchType, or defaultCase.

FG-4329

@snosenzo snosenzo requested a review from jtbandes August 29, 2023 21:24
@jtbandes
Copy link
Member

@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 {
Copy link
Member

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.

Copy link
Collaborator Author

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

Comment on lines +35 to +36
get cases(): Case[] {
return this.astNode.cases.map((def) => {
Copy link
Member

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 getters vs. computing them once and storing them as members?

Copy link
Collaborator Author

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],
Copy link
Member

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.

Base automatically changed from sam/fg-4327-recursive-typedef to main August 30, 2023 13:56
@snosenzo snosenzo force-pushed the sam/fg-4329-process-and-resolve-union-definition-for-serialization branch from 7329e5c to a1534dc Compare August 30, 2023 14:07
@snosenzo snosenzo marked this pull request as ready for review August 30, 2023 14:07
@snosenzo snosenzo merged commit 7fe4a3a into main Aug 30, 2023
1 check passed
@snosenzo snosenzo deleted the sam/fg-4329-process-and-resolve-union-definition-for-serialization branch August 30, 2023 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants