[quote="wjwwood, post:6, topic:6371"]
For me the obvious case solution is to provide a linter, enable it by default, and provide a convenient way to silence the linter in particular cases that youre unwilling to change, a la `# noqa` .
[/quote]
:+1: on this solution + maybe a "convention" disallowing this opt-out for new messages in core packages.
I'm still not convinced on the `CameraInfo` case. I do agree that consistency by itself is valuable in particular also for the core messages and maybe this is a good time to improve things, but from past experience with writing datatype converters between different systems (a few iterations of of ROS1 + X) I still believe that ease of transition in this particular case is more valuable. (But then again, I don't really know what overhead is really incurred by changing message and field names in this case, so it's hard to judge for me.)
[quote="Ingo_Lutkebohle, post:8, topic:6371"]
Still, for the future, why not ensure more consistency. No harm, right? There is no *advantage* of either naming convention over the other, we just have to pick one.
[/quote]
Fully agreed on no harm / only benefit, if we consider only new messages and leave legacy as they are.
[quote="Ingo_Lutkebohle, post:8, topic:6371"]
To get rid of the warnings, we can put messages on a legacy list or something like that.
[/quote]
"Legacy list" sounds like a centrally managed solution (probably you didn't mean that anyway), but we would need is an in-package per-message opt-out option (a la `# noqa` as William mentioned).
[quote="bgmoon, post:7, topic:6371"]
Why not make case and _ transparent so that they may be optionally used for documentation clarity, but from a programatic perspective these would all be the same:
[/quote]
Not sure about this, sounds to me like more potential for things going wrong, as IMHO it is a surprising convention for people that are not already familiar with the rules and thus is likely to result in tools / scripts that work in many cases, but break in surprising ways since this rule was not accounted for.
Even very simple things like topic names `foo/bar` and `/foo/bar` not being treated equal has caused me many a headache in rosbag processing.
---
[Visit Topic](
https://discourse.ros.org/t/relaxing-ros2-topic-service-field-name-restrictions/6371/9) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)