Hey all, 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. 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. 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). 3) Have interface multiple inheritance so that, for example, all properties of grob-interface are accessible by side-position-interface. 4) In cases where a grob implements multiple interfaces that have the same property, the property must be specified as property@interface (padding@side-position-interface). 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? Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel