Re: Context aliases

[Erik Sandberg]

On Tuesday 07 November 2006 12:22, Han-Wen Nienhuys wrote:
> Erik Sandberg escreveu:
> > On Monday 06 November 2006 17:02, Han-Wen Nienhuys wrote:
> >> Erik Sandberg escreveu:
> >>>>> I think this will be an improvement, because we remove the concept of
> >>>>> aliases, which confuses users (at least it confuses me a bit); in
> >>>>> addition we don't need to do anything extra to softcode aliases.
> >>>>
> >>>> I don't understand. How will this work in practice?  Ie. if I do
> >>>>
> >>>>    \set Timing.measurePosition = #..
> >>>>
> >>>> how will it be processed?
> >>>
> >>> We will have to change that to an \applyContext which finds/creates a
> >>> context with the 'timing property set, something like
> >>> \findContextWithPredicate #'timing \set measurePosition = #...
> >>
> >> I still don't understand why you want to scrap it.
> >
> > The main reason is to have one event less in the stream API (if we will
> > keep the current alias mechanism, I will have to create an add-alias
> > stream event). IWBN to keep that API minimal, and to me it seems that
> > aliases aren't much used anyways.
> >
> > However, you have a very point that functions like \applyoutput will get
> > more complicated if we want to keep full backward compatibility.
>
> I wouldn't say that they are not used often. Every \override and \set
> would start use  \findContextWithPredicate. Eg.
> RhythmicStaff/RhythmicVoice  has a \context Staff / \context Voice
> alias. That doesn't strike me as a tight API.

Good point. \set Foo.bar where Foo as an alias is a syntactical luxury which 
it's unnecessary to kill. Unrelated to this, it's problematic that staff 
names are used as aliases: When you do \set Staff.foo=..., it may happen that 
you don't want to set foo if we are in a RhythmicStaff, this is difficult to 
achieve if RhythmicStaff has a Staff alias. IMHO, it would be nicer if 
context names were never used as aliases.

However, aliases are not much used in the back-end; so we could still do the 
API minimisation (i.e., move aliases to context_handle, and make sure all 
alias calculations happen on the iteration side). The only problematic part I 
found in the back-end was the autoAccidentals list, which begins with a 
context alias. I don't understand that mechanism; is there a reason why we 
don't let the user decide which rules to apply where, by setting 
autoAccidentals to different values in different contexts?

> Is it necessary to solve this problem now?

No, I just wanted to take the discussion early.

-- 
Erik