lilypond-devel
[Top][All Lists]
Advanced

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

Re: implementation plan for music streams


From: Erik Sandberg
Subject: Re: implementation plan for music streams
Date: Thu, 4 May 2006 21:32:17 +0200
User-agent: KMail/1.9.1

On Wednesday 03 May 2006 11:07, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> >>>>> LY_DEFINE (ly_make_listener, "ly:make-listener",
> >>>>
> >>>> scm-listener-scheme.cc
> >>>
> >
> > sorry, I don't do stuff I don't understand. I have renamed the class and
> > placed it in a file listener-scheme.cc, hope that's sufficient.
>
> the idea is to separate the external GUILE interface ( foo-scheme.cc )
> from C++ implementation (foo.cc). We do this separation anywhere, and it
> will be the first thing I would have to change back; can you save that
> effort? Thanks!

Sorry to be stubborn, but ...

The Listener_scheme class is really just a wrapper that makes the Listener 
class accessible from Guile, so I view the class definition itself as a part 
of the GUILE interface of Listener.

There is absolutely no use for the Listener_scheme class outside 
listener-scheme.cc, so it would be a bit silly to create a separate .hh file 
for that class. The situation is similar for e.g. grob-pq-engraver.cc.

If there's a rule that LY_DEFINEs should be in their own files, then there are 
some inconsistencies:
$ grep -l LY_DEFINE *cc |grep -v scheme.cc
all-font-metrics.cc
file-name-map.cc
function-documentation.cc
grob-pq-engraver.cc
identifier-smob.cc
ly-module.cc
main.cc
music-function.cc
pfb.cc
profile.cc
program-option.cc
script-column.cc
simple-closure.cc
smobs.cc
text-metrics.cc
translator-ctors.cc
ttf.cc

-- 
Erik





reply via email to

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