Per f2f with @joemasterjohn. Unlike specific child APIs like RevoluteJoint::set_default_angle(), Joint::set_default_positions() does not propagate the changes down to the underlying model.
Make Joint::set_default_positions() an NVI to a pure virtual, protected, Joint::do_set_default_positions().
This will force derived joint types to do the right thing in Joint::do_set_default_positions().
Specific APIs such as RevoluteJoint::set_default_angle() would now have a simpler implementation in terms of Joint::set_default_positions().
BTW If you're going virtual you can't make any guarantees on what the actual implementation of do_set_default_positions() does which suggests that you can't actually use snake_case and should instead go for SetDefaultPositions() and DoSetDefaultPositions().
Not strictly true, I think. You _could_ guarantee snake_case if you specify in the do_foo doc that all implementations must meet our GSG requirements. Whether you _should_ restrict them as such is another question, but you do have the option.
I'm up for either, but I think we might as well make everything conform at the same time. For instance, joint.h has a few snake case virtual methods: do_get_velocity_start(), do_get_num_velocities(), do_get_position_start(), do_get_num_positions() that do not have such a restriction documented. What would that doc look like?
What would that doc look like?
Anything that would convey to you as a subclass author what you need to do. My first take would be:
/** Implements get_foo() via subclassing. Implementations must meet the
styleguide requirements for snake_case accessor methods. */
virtual const Foo& do_get_foo() const = 0;
(Admittedly the comment is somewhat redundant since snake_case functions must _always_ match the styleguide in any case, but perhaps its worth the little extra text a reminder.)
Resolved by #13757.
Most helpful comment
Anything that would convey to you as a subclass author what you need to do. My first take would be:
(Admittedly the comment is somewhat redundant since
snake_casefunctions must _always_ match the styleguide in any case, but perhaps its worth the little extra text a reminder.)