On Thu, Aug 09, 2001 at 02:29:01PM +0000, Mikhael Goikhman wrote: > On 08 Aug 2001 14:57:41 +0200, Dominik Vogt wrote: > > > > On Wed, Aug 08, 2001 at 04:45:34AM +0000, Mikhael Goikhman wrote: > > > > > > 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. > > Are not scripting language and extensible solutions orthogonal? > > Maybe we speak about different meanings of extensible solution, or you > really prefer to solve all new and old problems separately? For example, > if there is a need to do the following > > 1) Add an alternative command to conditions > 2) Try several file names to Read > 3) Determine that a module was not started > 4) Determine a timeout in some commands > > you suggest to alter a syntax of Next, Read, Module, ModuleSynchronous and > others, instead of identifying that all these problems are actually one > if-else problem and implementing an extensible solution, like command > statuses and "Otherwise", without a need to change any existing syntax? > With this solution, solving more similar problems is done by adding a line.
I'd rather rewrite the syntax 20 commands than extend the command parser in such a way. Currently it is *the* worst piece of fvwm code: not extensible, hard to understand, undpredictable, buggy. > Or another example of extensible solution. We currently only need a > command status True/False, so we go with Boolean by adding it to many > places. But tomorrow we will need another Boolean, so we should add it to > the same places again. An extensible solution would suggest that we will > need more than a Boolean in the future and do it in the first place. Changing the signature of a function always causes some changes in the code. By the way, I *did* say that I think implementing any kind of return codes is not a good idea. > > > 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. > > You are right, there is a common problem with synchronizing commands from > the same stream in concurrent environment. But there are no problems if > these commands are Read from a file, because another command can't get > executed until the file is finished. > > So I still think that Otherwise outside of functions is useful, although > it is almost useless interactively. You are right: it can only work inside complex functions and "Read" files and fail from modules and the command line. I guess then my proposal is still the most sound one: easy to implement, the patches are limited to a single file, helps with the most basic needs some users have and does not encourage difficult to implement enhancement requests. In my eyes, we can only think about scripting support in the command parser if we are prepared to throw away the whole code in functions.c and write it from scratch - which explicitly means that the most central part of fvwm becomes incompatible to older versions. 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]
