Re: possibility of merging \override and \set (was: Naming, _another_ lacking puzzle piece)

[Mats Bengtsson]

On 10/14/2012 07:36 PM, address@hidden wrote:
> Please, can we get away from thinking in terms of implementation details
> and instead think of the use cases:
>
> 1) Just set a property (grob or context property) to a certain value,
> don't worry about previous values
> 2) Set a property to the defaults
> 3) Temporarily set a property to a new value, being able to switch back
> after a while
> 4) Switch back to a previous value
Good view point. However, trying to think as a regular user, I see no 
point in distinguishing between use case 1) and 3). Why should I need to 
distinguish between a setting that can be reverted and one that cannot? 
To understand the need for difference, I would need to understand at 
least a bit of the implementation details, namely that 1) uses less 
memory than 3), which is becoming more and more of a non-issue given the 
amount of RAM and virtual memory of todays computers.

For many years, I viewed the difference between set/unset vs. 
override/revert as just different command names for context properties 
vs. grob properties. It wasn't until David first started asking about 
the exact differences, that I became more aware of the other 
non-symmetries between the commands. It is of course important to 
clarify all these details, even if you often can survive using LilyPond 
without having to bother about the details.

I haven't followed the full discussion, just browsed through some of the 
emails, however I agree with the objections against using "push"/"pop" 
as command names, since they only really make sense to those of us who 
have an M.Sc. in computer science and not to a musician. Surely, we can 
have a quick introduction to the concept of stacks in the documentation 
(for example comparing to a deck of cards) but conceptually, the names 
"override" and "revert" make at least as much sense for the layman and 
even if the names at least currently are slightly misleading, the 
analogy is still much better than some other analogies used in computer 
interfaces (the Mac concept of dragging the disk to the waste basket in 
order to eject it, comes to my mind as a terrible analogy).

   /Mats