In general as mentioned by @TheDash and @Paul_Bovbel you must defer your initialization until later in the cycle.
To support loading components not known about at compile time we must require a standard uniform API of all components for the loader to interact with. Almost all plugin systems work with a minimum common API (often implemented in C++ as a base class) and a registration/discovery mechanism for the loader to find available plugins. Sometimes the registration/discovery also includes descriptions etc.
Using parameters is the recommended way to configure nodes as this is the way that configuration can be made at run time by users.
With respect to ROS 2. I'd suggest making sure you're familiar with our [overview of composition](
https://github.com/ros2/ros2/wiki/Composition) as well as our vision of a [managed node](
http://design.ros2.org/articles/node_lifecycle.html) which adds a standard lifecycle on top which we can provide standardized tooling for managing ROS systems. This also gives a standard way to do initialization, configuration, and other transitions.
For comparison you can also explore the [nodelet API](
http://wiki.ros.org/nodelet) in ROS1.
---
[Visit Topic](
https://discourse.ros.org/t/using-classloader-with-nodes-and-non-default-constructors/2018/4) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)