Subject: Re: CVS domivogt: * Renamed On -> Test, Cond -> TestRc, CondCase -> "TestRc KeepRc".

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 20 Jul 2003 21:53:24 +0300

On 29 Jun 2003 08:43:37 -0500, FVWM CVS wrote:
> 
> Log message:
> * Renamed On -> Test, Cond -> TestRc, CondCase -> "TestRc KeepRc".

I can't say I like very much name TestRc. I have a suggestion that makes
names to be single words. For me they are more simple and intuitive:

  rename On, now Test                   ->  Given
  rename Cond, now TestRc               ->  On
  rename CondCase, now KeepRc TestRc    ->  KeepRc On

Here is my reasoning why I think it is more intuitive. The problem with
the test(1) association is that it is too weak and neutral, I may say:

  test -x /usr/bin/xmessage && echo 1

and:

  test -x /usr/bin/xmessage || echo 1

I.e. test as we know it from shell may be used for both "then" and "else".
However, "given <something>" means "if <something> _then_". Similarly,
"on <result> do" means "if we have <result> _then_ do". Just what we need.

For example, here is the syntax in the current cvs:

  Test (Init) Exec exec xterm
  Test (Version 2.5.*) Echo Do not run betas
  Test (f $[HOME]/.fvwm2rc) Echo Move ~/.fvwm2rc to ~/.fvwm/

  Next (FvwmConsole) Focus
  TestRc (Match) Raise
  TestRc (Error) Echo This is probably can't really happen
  TestRc (NoMatch) Module FvwmConsole

When I read this, I can't immediatelly recognize that the if-then
contruction is used. The following looks better for me:

  Given (Init) Exec exec xterm
  Given (Version 2.5.*) Echo Please do not run betas
  Given (f $[HOME]/.fvwm2rc) Echo Suggestion: move ~/.fvwm2rc to ~/.fvwm/

  Next (FvwmConsole) Focus
  On (Match) Raise
  On (Error) Echo This is probably can't really happen
  On (NoMatch) Module FvwmConsole

Like I wrote in one of my previous messages I would unite these two
commands into one Given, but this requires some additional code, so
having separate commands, Given (for any non-window conditions) and On
(for comparing the return code of window conditions), seems good to me.

Regards,
Mikhael.
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 21 Jul 2003 09:19:24 +0200

>   rename CondCase, now KeepRc TestRc    ->  KeepRc On

I decided against these terms for three reasons:

 1) "On" and "Given" are not commonly used in programming or
    scripting languages.  I wanted to stick with terms that are
    widely used for checking conditions.
 2) The names do not indicate that only function return codes are
    tested which may be confusing.  I think you wouldn't be happy
    with "OnRc".
 3) For non-native English speakers the terms "On" and "Given" are
    often confusing.

> (for comparing the return code of window conditions), seems good to me.

For me it's vice versa.  I'd never catch the idea that "On"
denoted a conditional command unless I knew it before.  It's only
intuitive if you are already aware that it refers to conditions,
not to switching something on or off.  Likewise, "Given" is very
ambiguous when read out of context.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 21 Jul 2003 16:08:19 +0300

>     widely used for checking conditions.

For the same reason "Test" is not used in programming languages to mean
the if-then construction that we need. The purpose of test(1) is to set
the shell return code "$?" and just this. We need something else, a
conditional. Actually "given" is a keyword in Perl 6 for "switch".

>     tested which may be confusing.  I think you wouldn't be happy

IMHO, "OnRc (Error)" is a bit better then "TestRc (Error)", but
"On (Error)" is even better when we need a single word comparison.

>  3) For non-native English speakers the terms "On" and "Given" are

We can't really know this, but I think we may ask on [email-masked] which
of the 2 syntaxes below the native and non-native English users prefer.

> ambiguous when read out of context.

I tried a lot of alternatives before suggesting these terms. I would like
to find clear terms. We have 2 conditional commands, one that requires a
single return code name and one the requires a more complex non-window
condition.

"Given" is not any more ambiguos than "Test". It sounds like a
conditional command. "Test" sounds like we are going to run some
diagnostics and probably to set some return code that is not the case.

When checking for a single return code, "On" seems to be very good:

  On (Success) do something
  On (Failure) do something different

It is possible that my sense of English is bad, but what do others think?

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 21 Jul 2003 09:26:51 -0400

> It is possible that my sense of English is bad, but what do others think?

I agree with Dominik.

On and Given are too ambiguous.

"ON" isn't too bad, its a common idiom from PL/1, and
COBOL, but I can't think of any common UNIX language that
uses "ON".

I can't find anything that uses "GIVEN".

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 21 Jul 2003 18:27:49 +0300

> On and Given are too ambiguous.

Do you say that for you "On" and "Given" is more ambiguous then "Test"
and "TestRc"? Then I think we should ask our users, because anything we
say about what would be ambiguous or not is only our conjectures.

I would like to find better terms, I just can't find anything that is
more intuitive _for me_ than "On (Success)" and "Given (Version 2.5.x)".

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 21 Jul 2003 12:48:01 -0400

Mikhael Goikhman <[email-masked]> writes:
> and "TestRc"?

Yes.  Maybe non-intuitive is a better word than ambiguous.

> Then I think we should ask our users, because anything we

Its more of an opinion than a conjecture.  :)

> more intuitive _for me_ than "On (Success)" and "Given (Version 2.5.x)".

I have no objection to gathering more opinions (conjectures).