On Thu, Jul 5, 2012 at 8:44 AM, m...@apollinemike.com <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 <
> m...@apollinemike.com> wrote:
>
>> On 4 juil. 2012, at 20:10, Marc Hohl wrote:
>>
>> > Am 04.07.2012 13:29, schrieb David Kastrup:
>> >> Marc Hohl <m...@hohlart.de> writes:
>> >>
>> >>> Hello list,
>> >>>
>> >>> the topic is somewhat over my head, but perhaps someone with more
>> >>> insight can answer this question?
>> >> I think that gcc likely can, don't know about g++, and we don't want to
>> >> rely on it anyhow.
>> > Ok.
>> >
>> > Well then, is there an alternative?
>> >
>> > I want to get rid of bar-line.cc (issue 1320), and I have managed to
>> get all
>> > definitions but Bar_line::non_empty_barline into scheme.
>> >
>> > In lily/note-spacing.cc, I have
>> >
>> > Grob *bar = Pointer_group_interface::find_grob (right_col,
>> > ly_symbol2scm
>> ("elements"),
>> > Bar_line::non_empty_barline);
>> >
>> > The simple approach
>> >
>> > bool non_empty_barline =
>> > ly_scm2bool (scm_call_1 (ly_lily_module_constant
>> ("bar-line::non-empty-barline"), right_col->self_scm ()));
>> >
>> > with
>> >
>> > (define-public (bar-line::non-empty-barline grob)
>> > (and (grob::has-interface grob 'bar-line)
>> > (pair? (ly:grob-extent grob grob X))))
>> >
>> > doesn't work.
>> >
>> I just realized that there's an easier way to do this w/ existing code
>> conventions. You can overload Pointer_group_interface::find_grob so that
>> it accepts a simple closure as the third argument. Then, wrap the Scheme
>> function in a simple closure.
>>
>>
> 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. 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.
Cheers,
Joe
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
