Erik Sandberg schreef
This doesn't sound like a very clean solution, which is troublesome
given that the original (IIRC) motivation was to clean things up.
Not necessarily; the unclean workarounds are temporary and isolated, and will
only last until we decide to drop backward compatibility.
I don't see the point of temporary workarounds: either we solve a
problem completely or we don't. There's nothing as long-lasting as a
temporary workaround.
In any case, I think I've found a decent alternative: We can let all music
events stay more-or-less as they are, but junk event-chords (use
simultaneous-music instead), and make music-events use their own iterators.
These iterators will perform any necessary duration-callbacks etc, and then
create and send a stream event around each music-event's mutable property
alist.
Yes, sounds like a sensible alternative.
Regardless of what we decide as the 'final' music expression format, this
feels like a good intermediate step.
BTW: May I change Sequential_iterator::get_music_list to return something like
scm_call_1 (get_music ()->get_property ("child-list-callback"), get_music
()->self_scm ());
?
This would make it possible to soft-code e.g. percent-repeat-iterator.
Why? If you want to make thing softcodable, why don't you make
iterators themselves softcodable? ie. init the virtual functions with
Scheme procedures.
(ly:make-scm-iterator my-process my-pending-mom my-construct-children)
but, all in all, I don't see what advantage this would get us.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
