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

updating switchcontrollers #96

Merged
merged 1 commit into from
Feb 11, 2020
Merged

updating switchcontrollers #96

merged 1 commit into from
Feb 11, 2020

Conversation

biofotis
Copy link
Contributor

@biofotis biofotis commented Feb 10, 2020

Proposed changes

fixing the error for the new message for melodic

Types of changes

What types of changes does your code introduce?

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. This is a reminder of what we should look for before merging this code. I have:

  • Read and follow the contributing guidelines.
  • Checked that all tests pass with my changes
  • Added tests (automatic or manual) that prove the fix is effective or that the feature works
  • Added necessary documentation (if appropriate)
  • Added the corresponding license to each file and add the current year of any one that you modified.
  • Tested on real hardware (if appropriate)

@beatrizleon beatrizleon merged commit dbf667c into melodic-devel Feb 11, 2020
@beatrizleon beatrizleon deleted the fix_melodic branch February 11, 2020 17:04
@guihomework
Copy link
Contributor

this fix will break again next time a message change occurs. Why not instantiate a SwitchControllerRequest which would have any new field already setup to default values.

@biofotis
Copy link
Contributor Author

Yes we can do that as well. I wasn't so sure about the defaults values as they might didnt work well with hardware. I confirm they do after testing it. Please feel free to update it with a PR

@guihomework
Copy link
Contributor

So you mean that it would actually be a "safety" feature to still call with given fixed set of parameters, and in case parameters are added, it will break and then somebody will look at it, whereas with my idea, default values might break things and/or get unnoticed.

I think your way is still risky because if parameters change "order" (maybe never happens) the call might send wrong values to wrong parameters and also be unnoticed.

I will provide a PR and you will decide to merge it or not.

@guihomework
Copy link
Contributor

done here #97

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants