Re: Use more const Grobs in the Paper_column interface (issue 346100043 by address@hidden)

[dak]

On 2018/06/19 23:44:57, Dan Eble wrote:
> On 2018/06/19 23:15:42, dak wrote:
> > evaluation.  Due to the significant timing constraints caching of
values is
> not
> > really conceptually const: in fact, a number of properties are
evaluated
> solely

> OK, well if get_property() is not even logically const (and if it
isn't, what
> is?) then the thing to do is to remove const from it, but I'm not
going to go
> there now.  I don't want to clean up after that.

> I'll withdraw this patch.

get_property_data is logically const (and used in a number of places to
avoid premature callback evaluatino).  Stream event and music
properties, I think, also are.  get_object is, I think.
get_pure_property may be (not entirely sure about that one, though).

We've had a number of early evaluation bugs, too, it's not really an
academical distinction.  I'm not against making "const" more useful for
deciding things but exactly in that case we want
Grob::get_property_internal _not_ be const.

https://codereview.appspot.com/346100043/