Make has_interface work with a const Grob *

Make has_interface work with a const Grob *

This required to change the predicate's type in the function
Pointer_group_interface::find_grob and some follow-up adjustments.
Other than that, I see no legitimate reason why this should not work.

[lemzwerg, 2019-11-04 18:59:23]

LGTM

[Dan Eble, 2019-11-04 21:07:59]

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...
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#...
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.

[hahnjo, 2019-11-05 18:34:25]

Correct const modifier

[hahnjo, 2019-11-05 18:34:30]

On 2019/11/04 21:07:59, Dan Eble wrote:
> 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.

I agree that these type of casts are odd, but I think the problem already
existed before this patch. The whole point of this one is that
internal_has_interface can be marked const and it's not violating constness.

[hahnjo, 2019-11-05 18:34:39]

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...
lily/grob-property.cc:183: Grob *me = ((Grob *)this);
On 2019/11/04 21:07:59, Dan Eble wrote:
> Behold!

Acknowledged.

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#...
lily/include/grob.hh:149: Interval extent (const Grob *refpoint, Axis) const;
On 2019/11/04 21:07:59, Dan Eble wrote:
> The prevailing style is to put "const" after the type.  See, for example,
> relative_coordinate() @ line 143.

Done.

[Dan Eble, 2019-11-05 19:21:03]

OK, go for it.

I think focusing the commit headline on Pointer_group_interface::find_grob would
hit the mark better.

[hahnjo, 2019-11-05 19:41:47]

On 2019/11/05 19:21:03, Dan Eble wrote:
> OK, go for it.
> 
> I think focusing the commit headline on Pointer_group_interface::find_grob
would
> hit the mark better.

The intention really is to make has_interface work, so I'd rather not. The
change to Pointer_group_interface::find_grob is just to avoid -fpermissive
warnings / errors because has_interface is passed as a predicate in one case.