message passing...

[Scott Ballantyne]

David R. Linn" <address@hidden> writes:
> Also, can you elaborate
> on where you think a message passing interface would work better (presumbably
> better than the current "inheritance" method (sometimes simply called
> "grouping" in other context)?
> 

Sure. First of all, what I perceive as multiple assignment operators
need to go, even if message passing isn't implemented. Recently, I
tried to write a context:

\paper {
       \translator {
                   \VoiceContext
                   \name CueVoice
                   ...
       }
}

\translator{\StaffContext \accepts CueVoice}

But this caused problems, since it was apparently overwriting the
existing StaffContext. To save the existing StaffContext, and still
use my own defined context, I ended up having to do (courtesy of one
of the developers, I couldn't have figured this out by myself, in my
present state of knowledge)

\paper {
       CueVoiceContext = \translator {
                       \VoiceContext
                       \name CueVoice;
       };
       \translator{\CueVoiceContext}
StaffContext=\translator{\StaffContext \accepts CueVoice};
}

\score{
        \paper {
               StaffContext = \translator {
                            \StaffContext
                            \remove "Time_signature_engraver";
                };
                \translator{\StaffContext}
      }
}

this prevented overwriting of the StaffContexts, which occured when
the '=' wasn't used. The developer who helped me out admitted that the
situation was confusing, which maybe was done to make me feel better
(it worked, if so), but I certainly find it confusing and needlessly
complex. It would seem simpler, and more congruent with what lilypond
is already doing, that '=' take care of the overwriting. (I would also
suggest that not overloading \translator would improve user
comprehension.) Then another mechanism, such as message passing, could
be used to modify the context:

    newcontext = \translator {...}

would create a new context.

      \sendmsg{\newcontext, message}

would modify it. With this model, the original CueVoice definition
would be something like:

\paper {
       CueVoice = \translator{\VoiceContext \name CueVoice }
       add_translator_to_system_list(\CueVoice} % eliminate
       % overloading of \translator, probably would be better to
       % eliminate this step altogether
       % and let \accept take care of it, if possible.
       \sendmsg{\StaffContext \accepts CueVoice}
}

\score{
        \paper{
                \sendmsg{\StaffContext \remove "Time_signature_engraver}
        }
}       

This contains all the information in the original example, side
effects are controlled, the user thinks in terms of creating new
objects, modifying them, or modifying existing objects through a well
defined interface. Under the present system, if something like
CueVoice is placed into a header file, and then advertised for use,
unpleasant surprises are certain to occur if someone has a
modification of StaffContext later in the file. It seems to me that
using the concept of modifying existing objects is not only less
likely to surprise, it's simpler to use, and easier to understand.

Note that a user could still completely replace any existing context, by
using '=:'

StaffContext = \translator {new staff context definition}

sdb
-- 
address@hidden