Re: Musings on interfaces and properties

[David Kastrup]

"address@hidden" <address@hidden> writes:

> Working on eliminating the translate_axis call from
> axis-group-interface, I've found a less-than-ideal situation in the
> naming/using of interfaces and properties that I'd like to clean up,
> but it'd be a major, major change and would take time to implement.
> So, before starting it as a project, I want to know if people think it
> is a good idea.
>
> Currently, interfaces can have whatever properties they want, leading
> things like `padding' or `staff-padding' to mean different things in
> different interfaces (tuplet-bracket-interface and
> side-position-interface, for example).  This is bad when you try to
> mix functions from the two interfaces together that think these
> properties mean different things.

Why would one want to mix?  Do we have grobs using both interfaces?

> To avoid this, there are a few steps we could take:
>
> 1) Require that, for a grob to use a callback from an interface, it
> must implement that interface.

I doubt that we should actually require that, but it's probably "all
bet's are off" terrain when one does differently.

> 2) Require that, for a callback to lookup a property, the property
> must be implemented by the interface that the callback is part of
> (i.e. ly:side-position-interface::y-aligned-side can only look up
> properties from side-position-interface).

Hm.

> 3) Have interface multiple inheritance so that, for example, all
> properties of grob-interface are accessible by
> side-position-interface.

We definitely should not think about "multiple inheritance" in the
current state of the code base.

> 4) In cases where a grob implements multiple interfaces that have the
> same property, the property must be specified as address@hidden
> (address@hidden).  Otherwise, LilyPond issues a
> warning and sets all paddings to the value for all pertinent
> interfaces.
> 5) In define-grob-properties.scm, specify all interfaces for properties.
>
> What do people think?

I think that at the current point of time, we should try getting along
with a flat namespace approach.  That might imply renaming properties
like "padding" to "side-padding" if we can't achieve reasonable results
otherwise.  Not sure about that.

Callbacks at the current point of time receive a "grob" as argument.  I
don't think that this "grob" should be converted to some subgrob pared
down to what the interface is "allowed" to see as it makes handling grob
identity a mess.

Point 1) makes some sense as a stipulation.  Trying to enforce this
stipulation, however, gets into variants of 2-5.  I don't think we
should at the current point of time go there.  The whole deal of context
and grob properties is too entangled to try cleaning them up separately.

-- 
David Kastrup