[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Make has_interface work with a const Grob * (issue 573210043 by addr
From: |
nine . fierce . ballads |
Subject: |
Re: Make has_interface work with a const Grob * (issue 573210043 by address@hidden) |
Date: |
Mon, 04 Nov 2019 13:07:59 -0800 |
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/