[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
message passing...
From: |
Han-Wen Nienhuys |
Subject: |
message passing... |
Date: |
Fri, 22 Sep 2000 10:06:37 +0200 (CEST) |
address@hidden writes:
> (I would also
> suggest that not overloading \translator would improve user
> comprehension.)
do you have suggestions for better naming? Would it be better to
overload \context, or should I add \contextdefinition?
> 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:
There are 2 separate issues: we have to have multiple translator
definitions for the same Staff context (for specifying eg different
implementations of staff), which is why we have
StaffContext = \translator{ ..}
PartStaffContext = \translator { .. \StaffContext .. [modifications] }
and there has to be a mechanism for selecting which implementation of
Staff you need for a specific paper block, which is what unadorned
\translator { \StaffContext .. }
is for. This is really a different type of assignment, if you want,
think of
Staff := \translator { \StaffContext }
instead
(Should we change this syntax too, and if yes, to what?)
> \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.
How would we get the toplevel context into the system?
> \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.
It has some other unpleasant effects, though:
\score { ..
\paper { }
}
\score {
\paper { \sendmesg { \StaffContext \remove "timesigs"; }
}
Would the 1st score be typeset with or without timesignatures?
The solution suggested by the idea that there is a single unique
StaffContext object would be to change the 1st score as well, and I
object to that.
Remember that processing is done after everything is parsed.
We could change that as well? Seems like an interesting idea. You
would get
\score { .. }
<crunch crunch, spits out .tex file>
\score { .. }
<crunch crunch, spits out another .tex file>
> Note that a user could still completely replace any existing context, by
> using '=:'
I'll try to think this over. I'll probably not use your ideas
directly, but I'll see what I can do.
--
Han-Wen Nienhuys | address@hidden | http://www.cs.uu.nl/~hanwen/
- Re: [Gnu-music-discuss] Inheritance?, (continued)
Re: [Gnu-music-discuss] Inheritance?, David R. Linn, 2000/09/21
message passing..., Scott Ballantyne, 2000/09/22
Re: message passing..., Mats Bengtsson, 2000/09/22