On 7/9/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> 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 _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
