Re: Project - Eliminating grob parents and, outside-staff-priority

[Mats Bengtsson]

On 09/27/2012 08:36 AM, address@hidden 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