Re: Make has_interface work with a const Grob * (issue 573210043 by address@hidden)

[nine . fierce . ballads]

This patch incites strong déjà vu.  I've vaguely concerned that some
status-quo uses of "const" are possibly misleading, and this patch is
then possibly just building on an unstable foundation.  I haven't formed
a very good sense of what C++ constness ought to signal where C++ meets
Scheme structures.

I've pointed out one place where const is casted away so that a Scheme
procedure can lazily initialize a Grob property--rather, IIUC, where a
Scheme procedure can do whatever it wants to any of the Grob's
properties, including the expected lazy initialization.


https://codereview.appspot.com/573210043/diff/577070043/lily/grob-property.cc
File lily/grob-property.cc (right):

https://codereview.appspot.com/573210043/diff/577070043/lily/grob-property.cc#newcode183
lily/grob-property.cc:183: Grob *me = ((Grob *)this);
Behold!

https://codereview.appspot.com/573210043/diff/577070043/lily/include/grob.hh
File lily/include/grob.hh (right):

https://codereview.appspot.com/573210043/diff/577070043/lily/include/grob.hh#newcode149
lily/include/grob.hh:149: Interval extent (const Grob *refpoint, Axis)
const;
The prevailing style is to put "const" after the type.  See, for
example, relative_coordinate() @ line 143.

https://codereview.appspot.com/573210043/