Sat, 28 Feb 2004 11:53:15 +0100, Han-Wen a dit :
> I'm ambivalent. The danger is that the number of functions to create
> and manipulate data structures explodes, and becomes harder to
> learn. We have to find a balance between having a small "interface"
> and an interface that is ultra-ergonomic to use. For the above case, I
> think make-music-by-name-and-props and is useful, althouh I oppose of
> the name. Why not have
> make-music-by-name
> take an optional alist or list of init values?
Of course, once there is a music maker that can have properties as
arguments, former make-music-by-name has no use.
By the way, why not `make-music'? I cannot find another
make-music-by-something in the sources. It would look like
(make-instance 'class-name ...options...) ==> instance of class-name.
[that's the way an object is created in CLOS]
(define-public (make-music name . music-properties)
"Create a music object of given name, and set its properties
according to `music-properties', a list of alterning property symbols
and values. E.g:
(make-music 'OverrideProperty
'symbol 'Stem
'grob-property 'thickness
'grob-value (* 2 1.5))"
(if (not (symbol? name))
(error (format "Not a symbol: ~a" name)))
(let ((props (hashq-ref music-name-to-property-table name '())))
(if (not (pair? props))
(error "Can not find music object" name))
(let ((m (ly:make-bare-music (cdr (assoc 'internal-class-name props)) props)))
(define (set-props mus-props)
(if (and (not (null? mus-props))
(not (null? (cdr mus-props))))
(begin
(set! (ly:music-property m (car mus-props)) (cadr mus-props))
(set-props (cddr mus-props)))))
(set-props music-properties)
m)))
(make-music 'OverrideProperty
'symbol 'Stem
'grob-property 'thickness
'grob-value (* 2 1.5)
'pop-first #t))
==>
<OverrideProperty :pop-first #t
:grob-value 3.0
:grob-property thickness
:symbol Stem>
If that's OK, I may build some patches.
nicolas
_______________________________________________
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
