Re: Translator todos

[Erik Sandberg]

On Wednesday 27 September 2006 22:05, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > Hi,
> >
> > Here's a summary of my plans for the translator (I assume all of this
> > will happen after 2.10):
> >
> > 1) separate context-def into two parts, translator information and tree
> > information. Basically, the info shared by engraver-init and
> > performer-init should belong to the 'tree information', which tells us
> > the relationships between context types, while the stuff specific for
> > layout and midi, such as translators and grob properties, should belong
> > to the 'translator' part. 2) remove recurse_over_translator and friends,
> > replace with a dispatcher system. This will probably be a slowdown, but
> > not in terms of O. 3) softcode \consists, \remove as music functions.
> > With the new event system, it shouldn't be difficult to add/remove
> > translators on the fly. Depends slightly on (2).
> > 4) remove Context::implementation. This member is currently only used by
> > translator groups, to search for parents and children. Once (2) is done,
> > it's sufficient to add a parent pointer to each translator group.
> >
>
> This all sounds very good. Of course (3) implies that we'll be able to
> run functions inside \translator definitions as well. I have the feeling
> that this might be a can of syntactic worms. To address that I think
> that it is better to do (1) before (3), because we can do (1) without
> user-visible changes, i.e. we don't paint ourselves into backward
> compatibility corners, while we gain understanding of how to do (3).

I have a clearer plan for context defs now: We could represent each context 
def as a Context object, which is used as a template for new contexts. E.g., 
the Voice context_def in engraver-init.ly defines a Context object with 
various engravers and properties in it, and when a new Voice is created 
during interpretation, the template voice is clone()d, and linked into the 
context tree.

This requires a good mechanism for context cloning, which preserves 
translators and context properties. This can be achieved using signals, much 
like the AnnounceNewContext mechanism: Context::clone sends a CloneContext 
event, containing a reference to the newly created context. When the 
translator group hears this event, it clones itself and all translators, and 
connects the clones to the new context (this should be sufficient to preserve 
\consists etc.)

This suggestion does still not make clear how to separate translator-specific 
and context-hierarchy-specific information, but we can wait with that 
separation.

Plan:
- create a Context::clone, which copies nothing.
- replace lots of references to Context_def with references to a Context which 
references that context_def.
- add hooks for translator groups (CloneContext event)
- incrementally stuff out from context def to context and translator group. 
This includes the commands \consists, \remove, \type,\override, \revert, \set 
and \tempo.

-- 
Erik