Ok, I need a refresher here. What was the ultimate aim of this patch/issue? As it stands, actual interface classes like Axis_group_interface don't have _any_ connection to a type any more. Instead, there is a Grob_interface template class depending on them with an arbitrarily named single instance not used for anything but initialization.
The interface classes act as containers for static member functions. That's basically useless: they are being used as namespaces without any coherent action. I think the ultimate motivation was to access grob member functions directly, by having member functions with a this-pointer set on the Grob, achieved via deriving from Grob. I remember objecting to that step based on the current design as the resulting inheritance hierarchy would not at all reflect any meaningful object relation and the actual instances of the created types would be rather meaningless. In particular, since interfaces would not be free to add non-static data members of their own, the necessary amount of up- and downcasting would not really correspond to any actual functionality. The reason I bring this up right now is that acknowledgers are part of engravers and tied to interfaces. These ties are currently established by symbol name. However, it would make more sense to actually tie the acknowledgers into the actual C++ construct for an interface, like XXX_engraver : Engraver { static Acknowledger <XXX_engraver, YYY_interface> YYY; static End_acknowledger <XXX_engraver, YYY_interface> YYY_end; ... }; Acknowledger <XXX_engraver, YYY_interface> XXX_engraver::YYY; // Can be done by template definition? void Acknowledger <XXX_engraver, YYY_interface>::acknowledge (Grob *) { ... } void End_acknowledger <XXX_engraver, YYY_interface>::acknowledge (Grob *) { ... } Of course, this is at best a rough sketch. The relation between the static member YYY and the actual acknowledger definition is tenuous at best. However, YYY_interface should provide the listening symbol and other stuff particular to one interface. And if interfaces are supposed to be definable purely in Scheme, they cannot only be defined via the static type system but need an existence as an actual _instance_. I don't see that the current approach is open for that venue. Sooooo. What I am getting too eventually: how strong are the reasons for retaining exactly the current interface representation? If I see a good possibility for tieing interfaces better into engravers, should I go for it in spite of it sabotaging the theoretical possibility to tie them closer into Grobs? https://codereview.appspot.com/251700043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel