David Kastrup wrote Friday, April 22, 2016 1:07 PM > I am currently doing pitch 2 at first-class Scheme engravers and am > sorely tempted to scratch the whole macro-based mess and do it via > inheritance and templates. > > Now the sore point is that the basic type for which Scheme functions are > defined is that of a Translator. And Engravers and Performers are > inherited from Translators, and it is only when inheriting from > Engravers/Performers that it is clear where the documentation is coming > from: static and specific to some Translator type, or dynamic and > defined per Engraver (as with Scheme engravers). Similar for some > dispatch tables. > > So the salient point would be to use virtual inheritance for access to > the translator documentation. We don't use virtual inheritance > elsewhere yet but, well, it's not like it hasn't been around a long time > now (basically since times before there even was a C++ standard other > than the ARM). So it's not a particularly new challenge for the > compiler, and its use would also be quite straightforward. I don't see > a comparably straightforward way to introduce documentation via a side > path, and it would also open up the path for having other translator > types (unspecific translators like the Timing_translator or even > performers) created dynamically by Scheme later on without having to > extend the macro mess. > > I think that would be considerably cleaner than dragging a number of > unused static components around for dynamically defined types. > > Any principal objections?
Not really an objection; just a thought. I can't comment on the technicalities, and I've every confidence you can carry this through, but I wonder about the position of existing compositions that include custom C++ engravers in the old (i.e. current) style. I guess there will be very few of these, but it would be a shame if they were to be limited to 2.18 stable without a rewrite. Might it be better to move forward to 2.20 before doing this so they could take advantage of all the 2.19 improvements in a stable release? Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
