On Wed, Aug 08, 2001 at 04:45:34AM +0000, Mikhael Goikhman wrote:
> On 08 Aug 2001 00:27:18 +0700, Dmitry Yu. Bolkhovityanov wrote:
> > 
> >     I've made a patch which implements a simple "if-else" syntax.
> > 
> >     A new "Otherwise" command is introduced (wouldn't clash with possible
> > future syntax enhancements, right?), which executes supplied command only if
> > previous command was unsuccessful.  So the syntax is:
> > 
> > AddToFunc "Do-this-or-that"
> > + "I" Next (SomeProggie) Close
> > + "I" Otherwise SomeProggie
> > 
> > (this implements Dominik's example of "if some window exists, kill it,
> > otherwise start it").
> > 
> >     Each command may return a True/False value, which defaults to "True".
> > This logic is implemented in execute_complex_function(), which sets the
> > "current return value" to True before calling a command.  There's no change
> > in command calling conventions, since "return value of this command" and
> > "return value of previous command" are global variables (sic!).  Changed are
> > only conditional commands, which set return value to False when
> > unsuccessful.  I also investigated if it would be possible to place these
> > two vars into exec_func_args_type, but those structs aren't passed between
> > *execute*function().
> > 
> >     Since return values are stored in global vars,
> > execute_complex_function() saves previous state and restores it on exit.
> > Unfortunately, it contained a number of returns, which had to be replaced
> > with "goto END_OF_FUNCTION" (I wish C had Ada/Perl "break from a block"
> > feature...).
> > 
> >     Of course, calling "Otherwise" outside a complex function is senseless.
> 
> Grr... :)
> 
> Before reading the mail I did my own patch that happens to be almost
> equivalent to yours, except for minor things. Say, I used interface
> functions instead of global variables (there is only one static variable).
> Also in my intention, functions may return more than just "success" or
> "failure". We may have in the future such "failure" codes like: "timeout",
> "window mismatch", "timeout", "incorrect usage", and the Otherwise command
> may have an optional parameter to distinguish between different failures.
> 
> In the future all CMD_* functions may return this value, that is "success"
> in most of cases. Currently it is not needed to minimize changes.
> 
> I called the function Else, because I hoped to have If in the future (for
> non-window conditions). But I have no objections to call it Otherwise.
> 
> In any way, this solution is more clean and extendible than the Dominik's
> one and it does not change any existing syntax.

Hm.  I'd really prefer a solution that is *not* extensible.  I
thought there was a common consensus that we don't want to
implement a scripting language in fvwm.

> So, if there are no
> objections I will apply the merged patch implementing this new command.
> 
> And BTW, it has sense (not yet) to call this command outside of functions.
> 
>   Read myfile1 quiet
>   Otherwise Read myfile2 quiet
>   Otherwise Echo Error: No myfile1 or myfile2 found

That's the best example I could think of why global variables are
*not* the way to go.  Whenever a command is executed outside a
function, there is a chance that another command gets executed
first and screws up the return code.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]

Reply via email to