Re: Implement \once as music function able to operate on complex stuff. (issue 5322065)

[dak]

On 2011/11/03 11:45:00, Reinhold wrote:

http://codereview.appspot.com/5322065/diff/3001/input/regression/complex-once.ly
> File input/regression/complex-once.ly (right):


http://codereview.appspot.com/5322065/diff/3001/input/regression/complex-once.ly#newcode11
> input/regression/complex-once.ly:11: \unHideNotes  g a
\once\hideNotes b c |
> While this is the easy approach, it builds on the fact that hideNotes
is
> internally implemented as a music expression with several \override
commands. If
> that internal representation ever changes, we won't have a proper
regtest any
> more...
> I would prefer to define the multiple property operations command
explicitly in
> the regtest, so we have complete control and no risk that a totally
unrelated
> change might break a regtest (without us even noticing).

> I.e. I would explicitly do
> multipleOperations = {
>    \override #'NoteHead #'color = #red
>    \override #'Stem #'color = #blue
> }

> and then \once\multipleOperations.

I disagree.  The whole point of redefining \once is to make it useful
for _existing_ functions/variables known to work by meddling with
properties.

Regtests also serve as illustrations of functionality.  Defining an
explicit sandbox for the regtest to work on is completely eliminating
its educational value.

I consider it very unlikely that changing \hideNotes in a manner where
it would either
a) work with the previous definition of \once
b) keep working with the new definition of \once while failing to work
   with a sandbox like the above
is feasible at all.

So I consider the regtest as _fully_ doing its intended job.  The whole
point of the change is that you can use \once on existing commands like
\hideNotes.  That's the desired and intended behavior.

http://codereview.appspot.com/5322065/