Hi folks, 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? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
