On 09/27/2012 08:36 AM, lilypond-devel-requ...@gnu.org wrote:
A typical example of this is NoteCollision of N NoteColumns. The
>NoteColumns have to all move in a coordinated way, and the easiest way
>is to have a function (with local variables) that determines what has
>to happen. You might get around it, by having a bunch of properties
>instead, but you'd still have to store those somewhere, ie in the
>NoteCollision grob.
Not necessarily, it'd just make computation time longer. If each note column
had other concurrent note columns in its side-position-elements grob-array and
we kept the same function from note-column.cc but rewrote it such that instead
of translating axes by values it returned the offset value for a given note
column, the function would be called N times for N note columns. It's a
tradeoff between efficiency and consistency - I'm not sure which one is better,
but I'm sure it's possible to eliminate the NoteCollision grob at the cost of
redundancy.
The main issue is which solution is easiest to maintain and extend for
future LilyPond developers. To me, it seems like it's easier to get an
overview of an implementation where a single centralized entity collects
all the necessary information and takes the decisions, compared to a
decentralized implementation where the information and logic is
distributed over a number of different objects. Admittedly, we already
have many examples of the latter strategy in the current LilyPond
implementation and I'm sure that it had contributed to the flexibility
and power of the general framework. Whatever solution is selected,
please don't forget to keep maintainability and generality as the main
guiding principle. This seems to be sometimes missing from the
discussions on the mailing list.
/Mats
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel