Re: Updating translators

[Erik Sandberg]

On 7/9/06, Han-Wen Nienhuys <address@hidden> wrote:
> the latter is safer. We can optimize if necessary later.
>
> >> rather use a derived_mark() and a vector<Event*>
> >
> > I think I'll use a native Scheme list.
>
> Hmm. That also adds some memory overhead (allocing and deallocing cells.)

OK, perhaps we can optimize that too later, if necessary.

> >> can you reengineer this to have less redundancy? I would expect that you
> >> can get enough info from
> >>
> >>    IMPLEMENT_TRANSLATOR_LISTENER (Arpeggio_engraver, arpeggio)
> >
> > I don't understand. What is redundant? I can't reacall any other place where I
> > give the information that the arpeggio method wants to hear events of class
> > ArpeggioEvent.
>
> the word arpeggio is in there thrice.

OK, I see.

First, I would prefer to make the second parameter of
IMPLEMENT_TRANSLATOR the exact method identifier; i.e.,  somethign
like
IMPLEMENT_TRANSLATOR_LISTENER (Arpeggio_engraver, arpeggio_event);
void Arpeggio_engraver::arpeggio_event (..)

Second: Would it make sense to deviate from naming conventions, and
name the listen method ArpeggioEvent, or should I rather perform some
dirty trickery to generate the class name from a GNU-style string?

I.e., should the listen method's name be
Arpeggio_engraver::ArpeggioEvent
or
Arpeggio_engraver::arpeggio_event
?

I imagine that the former could be easier to understand for a
beginner; after all, the keyword arpeggio_event in C++ usually
corresponds to symbol arpeggio-event
in scheme, so with it may be difficult for a poor grepper to find out
what's going on if strings are manipulated heavily under the hood.

Erik