lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: Project - Eliminating grob parents and, outside-staff-priority
Date: Thu, 27 Sep 2012 09:52:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Mats Bengtsson <address@hidden> writes:

> 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.

There is not actually much of a difference regarding the maintenance
level here as long as the information and logic is not distributed over
a number of different _code_ passages.

What we need is "to do x with y, you call z".  z may be an API function,
it may be a method of y.  What we don't need is "to do x with y, you
fiddle with y.z, try keeping w in sync by adding y.v here, and if there
is a w.g that has a common q with y.t, you need to make sure that the
pure callback of q.r is updated along with ..."

You get the drift.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]