On 4/22/16 6:07 AM, "lilypond-devel on behalf of David Kastrup" <lilypond-devel-bounces+c_sorensen=byu....@gnu.org on behalf of d...@gnu.org> wrote:
> >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. I think that if this can be done, it would be a great advantage. Using standard C++ constructs instead of LilyPond specific macros would help improve the accessibility of the code. Thanks, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
