Skip to main content

fully_qualified_name

Function fully_qualified_name 

Source
pub fn fully_qualified_name(
    node_name: &str,
    namespace: &str,
) -> Result<String<nros_node::::names::ResolvedName::{constant#0}>, ()>
Expand description

phase-381 follow-up — the node-FQN join, at the crate root because that is where a user looks after Executor::get_node_names hands them the two halves. nros_node::names also has expand_name / resolve_name, which stay behind node_metadata — they are the entity-name seam, not this. Phase 305 W3 (issue 0255) — the ONE name-resolution seam: ROS 2 source-name expansion (~/relative → FQN, ns=/ collapse) + launch remap substitution (exact-FQN match, first rule wins; no wildcards). Implemented in nros_node::names so both the Rust ExecutorSink and the C-ABI executor-side remap table share one lowering; re-exported here next to SourceNameKind as the source-metadata-level entry point. A node’s fully-qualified name, joined from its two halves.

/robot + talker -> /robot/talker; the root namespace collapses, so / + talker is /talker and never //talker. The namespace may be given with or without a leading /, and empty means root — the same input rules expand_name already accepts, because this IS expand_name’s private-name branch under the name people look for.

§Why a named function for one call

The join is three lines and the tree already contained THREE of them — Node::fully_qualified_name, the inline build in Executor::register_parameter_services, and this branch — which is the “one shared helper, never a second spelling” rule pointing at itself. It is also not discoverable: nothing says that expand_name("~", …) is how you ask for a node’s own name, so the fourth caller writes a fourth copy and gets the root case wrong. //talker is the failure this exists to stop.

The counterpart in ROS 2 is rcl_node_get_fully_qualified_name / rclcpp::Node::get_fully_qualified_name, but both answer only for the CALLER’S OWN node. Neither project has this one — the join for a node you DISCOVERED — because their graph APIs hand back two parallel arrays and leave correlating them to you. Ours delivers both halves in one visitor call, so the join is the only step left.