[Top][All Lists]
[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