For example, the Node::create_subscription() method has many arguments now, like:
- callback
- qos settings
- callback group
- ignore_local_publishers
- message memory strategy
- allocator
In the future it might have more, like other kinds of callbacks (e.g. on publisher match), intra process settings, etc. So it would be nice to convert the parameters that have default values in an options structure, in order to keep the signature short.
We can do other things to keep the quality of life for the users. I conceptualized this in the preview rclcpp overview in the core documentation:
From http://docs.ros2.org/alpha8/rclcpp_cpp_client_library_overview.html#advanced-alternative-ways-to-create-publishers:
auto publisher = node->advertise<geometry_msgs::msg::Point>(
"my_topic",
rclcpp::qos::profile_default | rclcpp::qos::best_effort | rclcpp::qos::depth(10));
Where you can see the convenient use of the | operator in something similar to the named parameter idiom to start with a default set of setting and customize it in line.
This would probably apply to most non-trivial classes in rclcpp, like Node, Publisher, Subscription, Service, Client, etc. They could all share common parts, like a wrapper around the rcl_qos_profile_t with the nice C++ syntactic sugar.
For example, the
Node::create_subscription()method has many arguments now, like:In the future it might have more, like other kinds of callbacks (e.g. on publisher match), intra process settings, etc. So it would be nice to convert the parameters that have default values in an options structure, in order to keep the signature short.
We can do other things to keep the quality of life for the users. I conceptualized this in the preview rclcpp overview in the core documentation:
From http://docs.ros2.org/alpha8/rclcpp_cpp_client_library_overview.html#advanced-alternative-ways-to-create-publishers:
Where you can see the convenient use of the
|operator in something similar to the named parameter idiom to start with a default set of setting and customize it in line.This would probably apply to most non-trivial classes in rclcpp, like
Node,Publisher,Subscription,Service,Client, etc. They could all share common parts, like a wrapper around thercl_qos_profile_twith the nice C++ syntactic sugar.