Re: locally changing global variables

[Jaroslav Hajek]

On Tue, May 11, 2010 at 7:13 PM, Søren Hauberg <address@hidden> wrote:
> tir, 11 05 2010 kl. 08:08 +0200, skrev Jaroslav Hajek:
>> On Mon, May 10, 2010 at 9:07 PM, Søren 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).
>
> Søren
>
> 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.
>

That's OK, I'm always all for better solutions. But I should warn you
that my definition of a solution includes a (working) implementation
:)

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz