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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
