-
Notifications
You must be signed in to change notification settings - Fork 418
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
Generate node interfaces' getters and traits. #1069
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
092b269
first try of node like something
Karsten1987 20bbf8e
Do not hardcode node interfaces for generation.
hidmic 235f8c1
Generate node interfaces getters.
hidmic 8d21dce
touchups
Karsten1987 1b28df4
use rcpputils::remove_pointer
Karsten1987 b7441e3
create_timer takes shared pointers
Karsten1987 ad10603
Add nullptr checks in node interfaces' getters.
hidmic 20795de
Fix node interface traits' tests.
hidmic File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
149 changes: 0 additions & 149 deletions
149
rclcpp/include/rclcpp/node_interfaces/get_node_base_interface.hpp
This file was deleted.
Oops, something went wrong.
149 changes: 0 additions & 149 deletions
149
rclcpp/include/rclcpp/node_interfaces/get_node_timers_interface.hpp
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 this is reasonable, but we will also break a lot of downstream packages if the old function returning a raw pointer is deleted.
IMO, we should deprecate instead of delete it.
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 agree, and we could so for
rclcpp::create_timer
, but not for the generated API (at least not seamlessly, template argument deduction won't be carried out for return types). #1035, on the other hand, doesn't drop API. Ultimately, there's a discussion about ownership that has to settled on.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 it's up to the class requiring the interfaces to decide if they need shared ownership or just a non-owning pointer.
IMO, we should only provide getters returning shared pointers, and deprecate the old ones returning raw pointers (which can be replaced with
get_shared_*_interface().get()
).But deleting that signature now will require a lot of changes in downstream packages.
I don't understand why it can be done in the generated API, I will check again tomorrow.
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.
It might not look pretty, but we should be able to write some empy conditions to check if we're generating getters for one of the previously existing interfaces and insert the deprecated API.
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.
Yes, template argument deduction won't work, but the same applies for the PR creating the files manually.
Both functions need to have a different name.
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.
Precisely, that's what #1035 does. We can make this PR do the same, though it'll take two deprecation cycles for the
std::shared_ptr
flavor API to get the name we intended it to have here.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.
That's a great point.
If you want to continue with the API breaking version, I can help with reviewing the PRs needed in the downstream packages.
It would also be good to add a comment in the release notes.
If you want to continue with two functions with different names, and optionally deprecate the ones returning a raw pointer, I also approve it.
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.
@jacobperron we need an executive decision here.
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 see. I'd rather not go through two deprecation cycles to get the API we want. I think it will be okay to have this API break and document it in the release notes.