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]
