change parameter separator to forward slash

[Karsten1987]

changes:

• change parameter separator from dot (.) to forward slash /
• exclude lambda condition for visibility
• use rcutils logging macros for warning

why?

this allows to correctly use the prefix when calling list_parameters

There are currently no unit-tests for rclcpp parameters (AFAICT). This should be ticketed separately.

[dhood]

is this change only necessary because of how you're setting the parameters (with a slash separating them instead of a dot)?
we have tests for list_parameters that work with the existing prefix, but only if you specify paramters using the same prefix.
If we make a change here it should be to make the prefix configurable, not switch from one arbitrary one to another IMO

[Karsten1987]

I would advocate for a convention on how to set the parameters (analog to how they are set in ROS1).
When loading a yaml file, e.g.

my_node:
  topics:
     sub: my_node_subscription
     pub: my_node_publication

I would set these parameters:

/my_node/topics/sub (= my_node_subsription)
/my_node/topics/pub (= my_node_publication)

But nevertheless, we could enhance the msg definition for separator field which may or may not default to some character.

[dhood]

I don't have an issue with it myself; others may have more context if there was a reason for the dots over slashes, but from the comment it seems like a placeholder.

Main point I wanted to make is that there is a convention at the moment (it's just a bit secret..) and list_parameters will only work with that specific one being used symmetrically. So this PR isn't fixing a broken list_parameters, per se, but instead is changing the convention to what ROS 1 users might expect. If we decide to go in that direction we have tests and demos that would need to be updated accordingly

[mikaelarguedas]

Looks like the place holder was chosen when we didn't want to use slashes anywhere, now that we do through namespaces I'm not sure that's a blocker anymore. I think the placeholder was chosen in a Java style and didnt have a strong rationale behind it

[Karsten1987]

updated the related tests.

CI:

[mikaelarguedas]

lgtm

[dirk-thomas]

Could this be const?

[mikaelarguedas]

Follow up on this: It seems like the rationale for not using / is to avoid ambiguity (mentioned on the parameters design document as follow):

"
Address all parameters without ambiguity in the names
For example, one of the challenges of the current system is that there is a naming ambiguity between nodes and parameters /foo/bar/baz could be a node /foo/bar/baz or a private parameter baz on node /foo/bar.
"