Am 05.07.2012 18:36, schrieb Joe Neeman:
On Thu, Jul 5, 2012 at 8:44 AM, m...@apollinemike.com
<mailto:m...@apollinemike.com> <m...@apollinemike.com
<mailto:m...@apollinemike.com>> wrote:
On 5 juil. 2012, at 08:14, Joe Neeman wrote:
[...]
On Thu, Jul 5, 2012 at 12:37 AM, m...@apollinemike.com
<mailto:m...@apollinemike.com> <m...@apollinemike.com
<mailto:m...@apollinemike.com>> wrote:
On 4 juil. 2012, at 20:10, Marc Hohl wrote:
Why not just leave the function in C++? I have nothing against
porting things to scheme, but in this case it just seems like an
exercise in making things more complicated, for no gain.
It's doable - the goal was to port the entire thing to Scheme.
You're right that it is much easier to write in C++.
I think it's exercises like that that help strengthen the Scheme
bindings and thus lead to more customizability/extensibility.
In this case, I disagree. The function in question is used in 2 places
in the C++ code, neither of which is a good candidate for customization.
I agree, I don't see a need for customization in this place, either.
The only argument for porting this function in the first place is that
it happened to live in the same file as some other stuff (which _did_
make sense to port). That doesn't sound like a very good argument to me.
If the funtion is not ported, where should it be defined?
Keeping bar-line.cc alive for the definition of one function feels kinda
weird,
so either I define the helper function in each file where it is used, or
is there
a better and more global place for this function?
Regards,
Marc
Cheers,
Joe
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
