[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Musings on interfaces and properties
From: |
David Kastrup |
Subject: |
Re: Musings on interfaces and properties |
Date: |
Wed, 27 Feb 2013 14:38:52 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
"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
- Musings on interfaces and properties, address@hidden, 2013/02/27
- Re: Musings on interfaces and properties,
David Kastrup <=
- Re: Musings on interfaces and properties, Werner LEMBERG, 2013/02/28
- Re: Musings on interfaces and properties, address@hidden, 2013/02/28
- Re: Musings on interfaces and properties, Werner LEMBERG, 2013/02/28
- Re: Musings on interfaces and properties, address@hidden, 2013/02/28
- Re: Musings on interfaces and properties, David Kastrup, 2013/02/28
- Re: Musings on interfaces and properties, address@hidden, 2013/02/28