Re: locally changing global variables

[Søren Hauberg]

tir, 11 05 2010 kl. 08:08 +0200, skrev Jaroslav Hajek:
> On Mon, May 10, 2010 at 9:07 PM, Soren Hauberg <address@hidden> wrote:
> > man, 10 05 2010 kl. 13:48 +0200, skrev Jaroslav Hajek:
> >> Octave's global pseudo-variables are a useful tool for customizing
> >> Octave's settings, yet they present problems when a function is
> >> dependent on a particular state of a certain variable. A typical
> >> instance in my work is console output magic used for progress tracking
> >> of a lengthy task that may be delayed or even completely spoiled by
> >> the pager. A temporary change of a particular variable can be achieved
> >> by unwind_protect:
> >
> > [snip]
> >
> >> Comments? Suggestions?
> >
> > I agree with your observation that the current syntax is a bit more
> > verbose than you'd really like it to be. The syntax you propose is
> > properly the least intrusive one, so that's good. That being said, it
> > would be a new (and possibly confusing) thing in the language if
> > functions can have an effect *after* they have returned. This is
> > essentially what you are proposing, although only for a small subset of
> > languages.
> >
> > In C++ (or any other OO language) the standard approach would be to
> > create a class with a constructor that set the value and a destructor
> > that would reset it. Perhaps something like this could be done instead?
> > Not sure if that would be more natural, though, as objects in Octave
> > generally don't have destructors.
> >
> 
> This is actually what is done internally. The closest thing in Matlab
> is the onCleanup class. With that, you'd need to write
> 
> old_pso = page_screen_output (false);
> c = onCleanup (@() page_screen_output (old_pso));
> 
> which is again wordy, though you at least don't need to enclose the
> whole function body. In Matlab, basically any m-function can achieve
> the same effect that I was proposing, by doing
> 
> function myfunc ()
>   c = onCleanup (@() doSomething()); % create a cleanup action
>   assignin ("caller", "c", c); % inject it into caller scope
> endfunction
> 
> Ergo, it is *not* a new thing in the Matlab language that functions
> can achieve effects after they're called.

Hmm, I guess that is correct. The syntax you propose is, however,
non-standard. This is not necessarily a bad thing, though. One
alternative syntax would be to define a function 'restore_on_return',
that you could call like this

  restore_on_return (@page_screen_output, false);

This should then call 'page_screen_output (false)' right away, and when
the calling function returns it would call 'page_screen_output' with the
output of the previous call as input. I'm not really sure this is better
than what you propose, except it would be easy to use on other functions
than the built-in ones (not sure how important that is, though).

Soren

P.S. Just to be clear: I think your suggested solution is just fine, I'm
just thinking out loud to see if there would be a better solution.