Public API in detail namespace - `rclcpp::node_interfaces::detail::NodeInterfacesSupport`
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cpp
- Domain
- api, documentation
Research direction
Start with the NodeInterfaces documentation linked in the issue and the documentation for rclcpp::node_interfaces::detail::NodeInterfacesSupport. Determine where the public-API status should be stated, then update the relevant documentation so users and maintainers can clearly tell whether this class is supported despite its detail namespace.
Written by the indexing model from the issue text.
Description
Description
From what I can find in the documentation on NodeInterfaces, the rclcpp::node_interfaces::detail::NodeInterfacesSupport class is meant to be specialized by users and thus is part of the public interface of rclcpp, however, it is part of the detail namespace explicitly called out as not public interface.
Since it is the only way to use the class with custom interfaces and is explicitly called out in the docs, I would assume it is part of the public interface. Should we maybe mark it more clearly on the rclcpp::node_interfaces::detail::NodeInterfacesSupport itself (both for users and future changes?).
I don't know if there is any other reason for it to be in the detail namespace. This functionality was added in #2041 and was like this from the beginning.
Motivation
Depending on implementation details of library is wrong, so we should be clear on whether this is public API or not.
Design / Implementation Considerations
I don't think it is feasible to change the namespace of the type, as that would break any existing users. The path of the header may be changed and the old one kept for compatibility if deemed necessary.
The most likely resolution I can think of is just an explicit note in the documentation that the class is part of the public API despite the namespace, so that both users and maintainers know, how to approach it.
Additional Information
No response
- Dominant language
- C++
- Stars
- 805
- Forks
- 564
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 26
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ros2/rclcpp
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
EventsCBGExecutor `spin_until_future_complete` hangs when passed as a generic `rclcpp::Executor` Openbug
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·