Re: \set vs \override

[David Kastrup]

Joe Neeman <address@hidden> writes:

> On Sat, 2009-11-21 at 17:22 +0100, David Kastrup wrote:
>> There is a chapter "set vs override" in the manual.
>> 
>> I am afraid that I fail to grasp the difference from the chapter.

[...]

>> If the element description is a _special_ type of context property,
>> that would imply that there is just _one_ different kind of
>> properties.  It completely fails to mention _what_ makes the element
>> descriptions special and not settable with \set.
>> 
>>     These properties are named in `StudlyCaps' (starting with capital
>>     letters).  They contain the `default settings' for said graphical
>>     object as an association list.  See `scm/define-grobs.scm' to see
>>     what kind of settings there are.  Element descriptions may be
>>     modified with `\override'.
>> 
>> So why can't we use \set with element descriptions?  And where is the
>> difference to context properties changing values?  After all, the
>> principal purpose of \override is also to change the value, and
>> \once\override very obviously changes behavior over time while
>> interpreting music.
>
> Since \override works by modifying special context properties, you can
> actually use \set for setting grob properties.  However, \override
> does some extra useful work: for a start, it appends new overrides to
> a list of overrides for a grob so that they can be easily reverted
> (\set just clobbers the existing variable).  Also, \override supports
> nested properties (useful for things like 'bound-details).  The
> type-checking mechanisms are also different for \override and \set.

You describe different semantics for \set and \override.  Then you
describe different restrictions.  And then you say that they have
different type-checking mechanisms.

The problem is that the different type-checking mechanisms are there for
the two different kinds of properties, but the whole thing appears
completely arbitrary: it is not clear why you would want to permit one
kind of command just with one set of properties, and the other with the
other.  I see no connection between the type of command you should use
and the kind of properties that are affected.

If you take a look at a recent proposal
<URL:http://codereview.appspot.com/152127/patch/1004/5>, \tweak (another
setter) is proposed to support nested properties.

I don't see a good rationale why \set, \override, \revert, \tweak should
not work on the same set of properties (including subproperties).  I
don't see an explanation why it makes sense to differentiate between
them.

And I am arrogant enough to believe that if I don't understand a design
decision after a few days of trying, it is likely that ultimately a lot
of people other than myself will be better off if the distinction gets
abolished.

-- 
David Kastrup