Comments (4)
Some history about rationale can be found on the ROS next gen SIG. Multiple threads mention interface files but I guess this RFC sums some of it up:
Hi,
we have a pending proposal to enforce stricter rules on the contents
of Interface files (.msg and .srv files), but this RFC is specifically
about the rules for field names in interface files. Currently we allow
upper case letters in interface files, e.g. CameraInfo has fields `D`,
`K`, `R`, and `P`. We'd like to restrict field names to all lowercase
and underscores (plus some other, less controversial rules). For a
full set of the proposed rules, you can look at this work in progress
design doc:
http://design.ros2.org/articles/interface_definition.html#conventions
The advantages to enforcing these rules (and consequently changing
field names in messages like CameraInfo) is that anyone can look at a
member of a generated message struct, e.g. `CameraInfo.D`, and tell if
the member is a field or constant. It also helps us avoid name
collisions in the generated code (similar to the rule about not having
trailing `_` nor double `_` in the field name). Also, having a style
and sticking to it has an inherent value and promotes good conventions
and more readable code.
The arguments against doing the change: An Indirect consequence of
these stricter rules is that it might encourage more non-trivial
changes to field names than would otherwise occur. For example, rather
than converting the field name `D` (an actual field name in
`CameraInfo`) to `d` as a result of these stricter rules, it might be
changed instead to `distortion_vector` for clarity. This is probably a
good thing, but it will add to the disruption of migrating to ROS 2.
For the ROS 1/ROS 2 bridge that would require some manually specified
conversion rule (similar to a rosbag migration rule) to perform the
conversion automatically. However, even with ROS 1.x, itβs relatively
easy to tell whether a member of a generated message is a field or
constant based on the context.
I think I've summarized the pros and cons of the issue well, but if
I've missed something please jump in and add to the conversation.
In the short term we will be turning on the strict enforcement and
changing the fields in the messages that are affected. In the
meantime, we'd like to also solicit feedback from you about this
issue, and if we reach a different conclusion based on pros or cons we
did not come up with, then we can change our policy and potentially
the message fields again.
Cheers.
https://groups.google.com/g/ros-sig-ng-ros/c/YAyfgrvUvs0/m/N0F5d1S5zqgJ
from design.
The original design article went in as part of #32 . There was no rationale given for that particular rule there.
The wording of "must" in that article is in RFC2119 style, which is why it is very imperative.
In short, we'd be OK with lifting this restriction. However, we do want to keep the core using only snake_case fields (for consistency), which we would want to do with a linter. Thus, in order to lift this restriction the following would need to be done:
- Develop a linter for .msg/.srv/.action/.idl files that enforces some rules, and optionally enforces others.
- Add something to ament_lint to enable that linter to be easily called from ament.
- Update the .msg/.srv/.action/.idl parsers to allow uppercase letters.
- Update https://github.com/ros2/design/blob/gh-pages/articles/116_legacy_interface_definition.md and https://github.com/ros2/design/blob/gh-pages/articles/110_interface_definition.md to allow that style.
We aren't likely to have time to do this, so if you'd like to contribute, we'd be happy to review PRs to do the above.
from design.
I've always understood the main rationale for the no-capitals rule-of-thumb to be the fact it significantly reduces possibility for errors and makes 'guessing' the exact spelling of fieldnames much easier.
My experience with other middlewares/code generation frameworks is that, despite the fact we have extensive code-completion support these days, no-capitals is very convenient. Personally, I believe it outweighs the fact fieldnames can't follow naming of things like mathematical expressions, but this is just one voice/data point of course.
from design.
Thanks for the historical notes @mikaelarguedas !
from design.
Related Issues (20)
- Middleware alternatives to DDS HOT 4
- fix login by using new GitHub methods HOT 1
- Changes between ROS 1 and ROS 2 design doc is out of date HOT 1
- Add support for fully qualified names in message defnitions
- Add design document on configuring QoS at startup time HOT 4
- Add support for preemption in actions HOT 39
- Update XML schema definition for launch files HOT 2
- Add [ros2 node kill <node_name>] and [ros2 node kill --all] (similar to [rosnode kill] from ros1) HOT 23
- Article numbering is not clear HOT 3
- Topic name constraints discrepancy HOT 9
- Documentation linter HOT 5
- zero-copy: shared memory using external mapped buffer HOT 3
- is intra-process communication meta-message transfered via DDS? HOT 4
- Logging Design Document
- Update Launch XML Schema HOT 3
- can we add a "date written" to the design docs? HOT 2
- Map char[N] to str in Python
- how you configured opentcs nena ros2 adapter to your agv? HOT 1
- where is the discauss of register callback and run callback? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from design.