Re: How to do this correctly?

[Carl Sorensen]

On 1/28/10 9:22 PM, "Han-Wen Nienhuys" <address@hidden> wrote:

> On Thu, Jan 28, 2010 at 11:49 AM, David Kastrup <address@hidden> wrote:
>> Carl Sorensen <address@hidden> writes:
>> 
>>> On 1/28/10 7:25 AM, "David Kastrup" <address@hidden> wrote:
>>> 
>>>> Anyway, I think that likely the ambitus engraver would be a good
>>>> candidate for reimplementing as a Scheme engraver.  It would appear
>>>> reasonably straightforward but not trivially so, and it is one of those
>>>> things where augmenting the _code_ and behavior is likely to be better
>>>> extensible in Scheme.
>>> 
>>> I think it would be difficult to implement as a Scheme engraver,
>>> because there need to be variables stored as part of the context that
>>> are modified by different event handlers.  But I could be wrong.  It
>>> wouldn't be the first time and is not likely to be the last.
> 
> do you mean engravers by 'event handlers' ?  I had thought the Scheme
> engravers to use context properties to store internal state, but if
> that is a problem, we could add another internal scope inside the C++
> engraver instance to store private data.  Public data can of course be
> shared as context property.

By event handlers I mean functions in the engraver that process events, e.g.
TRANSLATOR_LISTENER functions.

I also mean private functions in C++ engravers that have access to private
data in the engraver.

I believe that storing private data inside the C++ engraver instance would
provide the functionality that is used in most of the engravers I've looked
at.  For example, the Chord_name_engraver stores last_chord_ so that it can
decide when to create a new grob if chordChanges is #t.  Similarly,
Ambitus_engraver stores the minimum note and the maximum note.  I haven't
explored things carefully, but Neil said that the current implementation of
scheme engravers didn't have any place to store private data that would be
accessible to all of the member functions of the engraver.

Thanks,

Carl