lilypond-devel
[Top][All Lists]
Advanced

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

Dealing with nested properties.


From: David Kastrup
Subject: Dealing with nested properties.
Date: Wed, 03 Aug 2011 12:07:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

What is the general feeling about override/revert with nested
properties?  The current implementation for property list of grob
properties maintains a data structure suitable for lazy updates of the
spine of the grob property list.

However, overrides for nested properties duplicate part of the _leaves_
of property lists which then are not updated anymore.  Since alists are
not changed destructively, the update process for the spine of the
alists also gets triggered for changes in the leaves, but its effects
are restricted to updating the spine, so the copied environment of an
overriding leaf is not updated.  The resulting data structures can't
distinguish

\override whatever #'a #'the-current-default-alist-for-a-with-changed-elements
and
\override whatever #'(a b c) #'something-new

But the first should disassociate the entire list for a from changes in
parent contexts, while the second should merely disassociate a.b.c from
changes in parent contexts.

So there is no way that the current data structures will work
consistently with the desired semantics.  I see three ways of
proceeding:

a) Make things work as intended.
b) Document that override/revert are just a rough approximation of the
desired behavior, and make that approximation a good compromise between
usefulness and simplicity, so that people can understand what will fail
in what manner.
c) Remove access to nested property as it does not work.

I am currently working on angle a) but I am skeptical that it will
result in code that is both efficient as well as easily
understandable/maintainable.  I find the current code already tough in
that area.

-- 
David Kastrup




reply via email to

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