Re: Introduce a Grob_interface class (issue 251700043 by address@hidden)

[dak]

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/