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

[Carl Sorensen]

On 4/30/16 3:37 AM, "lilypond-devel on behalf of address@hidden"
<address@hidden on behalf of
address@hidden> wrote:

>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.

I can't remember the rationale for the previous change.  So I will just
have to jump in with my current impression.

The semantics of interfaces are a bit challenging.  In the internals
reference we talk about grobs having interfaces, meaning that any
properties contained in the interface should be able to be set for the
grob.

But in the code, the interfaces aren't actually part of the grob, they're
part of the engraver(s) that is (are) used to handle the display of the
grob.  And if a particular engraver doesn't implement a property that is
part of the interface, then for all practical purposes the grob doesn't
have that property.

It gets even more potentially confusing, because some grobs are handled by
multiple engravers (e.g. fingering_engraver and new_fingering_engraver).

So I can see that it would be desirable to have interfaces attached to
grobs, but it is also necessary to have interfaces attached to engravers.

>
>
>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.

Your proposal makes sense to me.  I would be in favor of moving in that
direction.

>
>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?

I think we should make the interface structure match the implementation of
the code as best we can.  To me, at this moment, that means we need to tie
interfaces to engravers and grobs, with engravers having the higher
priority, since that is where the code actually exists.  If we want to
make the code be part of the grob, then we could tie it more closely to
the grob.

Thanks,

Carl