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, reinh...@kainhofer.com, 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel