I think that good cases both for an against optional fields have been made here and elsewhere.
To add to them, I also think that the Python experience shows the value of optional fields for **function call type communication**. It can give an API more expressiveness and make more explicit how it is intended to be used correctly. I agree that it can also add a lot of complexity, but at least for services that complexity may be worth it. I think it depends on how the majority of ROS users are creating services. Are they being used as remote procedure calls, or are they more often used as two-way or pull-style pub/sub communication (e.g. pull a copy of the map only when wanted)? If it is the former, then perhaps optional fields should be considered for service definitions. Of course, that raises the prospect of reducing the compatibility between .svc and .msg definitions, which I think is probably not desirable.
---
[Visit Topic](
https://discourse.ros.org/t/optional-fields-in-message/991/14) 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)