Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add normalize_remap_rule and types #173

Merged
merged 2 commits into from
Feb 8, 2019
Merged

Add normalize_remap_rule and types #173

merged 2 commits into from
Feb 8, 2019

Conversation

sloretz
Copy link
Contributor

@sloretz sloretz commented Feb 1, 2019

I want to reuse the types and type checking on arguments to Node in ComposableNode. This PR does that for the remappings argument. I'd like to do the same thing for parameters, but thought I would split it up to get feedback sooner.

Adds remap rule types to and utility functions to type check and normalize remap rules.

Signed-off-by: Shane Loretz<sloretz@openrobotics.org>
@sloretz sloretz added enhancement New feature or request in review Waiting for review (Kanban column) labels Feb 1, 2019
@sloretz sloretz self-assigned this Feb 1, 2019
@sloretz sloretz requested a review from wjwwood February 1, 2019 23:05

SomeRemapRule = Tuple[SomeSubstitutionsType, SomeSubstitutionsType]
SomeRemapRules = Iterable[SomeRemapRule]
RemapRule = Tuple[Tuple[Substitution, ...], Tuple[Substitution, ...]]
Copy link
Contributor Author

@sloretz sloretz Feb 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is Tuple[Tuple[ instead of Tuple[List[ to make a normalized remap rule immutable. (Edit: well, the Substition instances in the Tuple aren't immutable, so I guess it's just less mutable)

There isn't anything called description yet, so currently I'm thinking a launch_ros.description.ComposableNode instance is an immutable description of some end state. Unlike an action instance which is only performed once, a description could be given to multiple actions. Defining the type as Tuple is a way to prevent remap rules on it from being modified.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: Tuple vs List, immutable is fine by me.

Re: launch_ros.description.*, is there a description base class for these? If not, I had imagined they would not be in a subpackage together. If so, then I think a module called launch_ros.description with a subpackage called launch_ros.descriptions.* would be most appropriate.

Otherwise, I think launch_ros.ComposableNode is just fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: launch_ros.description.*, is there a description base class for these? If not, I had imagined they would not be in a subpackage together.

Roger, launch_ros.ComposableNode it is

Signed-off-by: Shane Loretz <sloretz@osrfoundation.org>
@sloretz
Copy link
Contributor Author

sloretz commented Feb 2, 2019

Added tests in 1e0616c

CI (testing launch_ros, test_launch_ros)

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@sloretz sloretz merged commit 34f10c6 into master Feb 8, 2019
@sloretz sloretz deleted the normalize_remap_rules branch February 8, 2019 17:08
@sloretz sloretz removed the in review Waiting for review (Kanban column) label Feb 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants