Re: Naming _another_ lacking puzzle piece

[Reinhold Kainhofer]

On 2012-10-13 22:48, Joe Neeman wrote:
> If you are referring to Werner's and Reinhold's comments, I think you
> may not be reading them as the authors intended. In particular, I
> believe that Reinhold was merely objecting to the names "push" and "pop"
> as being opaque to non-programmers,

Exactly. The names push/pop are stack concepts that require thinking 
like a programmer (and to be honest, I'm still confused: Does "pop" 
popsomething into the stack or pop something out of the stack.... The 
only way for me is to think that it's the opposite of "push").

I completely agree that we need a function that changes a property in a 
non-destructive way. It is an implementation detail that this internally 
means a pure push on the grob properties' stacks, but I don't think that 
the interface we provide to the users/high-level developers should have 
the API of a stack, as that would require that we describe it to users 
(many of whom have no programming experience, and don't want to) in 
terms of stacks.

The internal handling of property values is via stacks, but for the user 
it is not about a stack, but about changing the value of a property, and 
later reverting it to a previous value (at least, I would expect that; 
currently we always revert to the default), or restoring the default.
That was my main objection to using "push" and "pop" as names: They 
reveal the implementation details (using a stack for the property value 
handling) rather than providing a high-level API that is centered on the 
purpose of the calls rather than the internals.


If we were to completely re-design the lilypond language, I would 
suggest \override, \revert and \clear (as push, pop and clear stack), 
but they currently have a slightly different meaning.


The real problems we currently have are that,
1) We don't have a function that sets a grob proparty non-destructively 
via a simple push,
2) although the name suggests otherwise, \override is a not really a 
temporary override, but a permantent, destructive value setter function.
3) \revert does not revert the effect of an override, but rather reverts 
to the default value...
4) Grop properties and context properties have different setter 
functions and concepts (\override vs. \set), which is not intitive to 
me, and hard to explain to a newcomer.
5) Any change will likely break backward-compatibility and introduce 
subtle problems (like things looking/behaving different without any 
warning).

Cheers,
Reinhold

--
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://www.kainhofer.com
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com