-
Notifications
You must be signed in to change notification settings - Fork 9
Add OfferedDeadlineMissed QoS event #17
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
Conversation
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
cfeb741 to
9dc7656
Compare
| public int totalCount; | ||
| public int totalCountChange; |
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 missed this for other statuses in previous PRs, but I think these member variables should be private and we can add getters for them. I think this will provide a bit better encapsulation (e.g. if symbol names change in the future, it's easier to deprecate a method than a member variable).
I don't think making them private has any impact on the native code setting their values.
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 think that passive data types only carrying data are a valid citizen in oop.
When the class doesn't have any invariant (relationship between fields) there's not much value on using private data, setters and getters.
if symbol names change in the future, it's easier to deprecate a method than a member variable
If we change the name of one of the members we're going to break all other clients, so I don't think that's going to happen.
I realized (late), that the generated java bindings for ROS messages doesn't expose the data and provides getters/setters instead.
Though I don't like that, maybe being consistent in event statuses is better.
If would prefer doing this change after merging all remaining PRs in the feature branch.
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.
Merged, we can solve this issue before merging the feature branch on master.
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'm ambivalent about it. Maybe we just leave it as-is and bring it up again when we open a PR upstream.
I'm not sure what the reasoning was to generating getters and setters for ROS messages; this too may be something we can change later upstream.
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.
Sounds good
rcljava/src/test/java/org/ros2/rcljava/publisher/PublisherTest.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.