Nabble - Rev Pilgrim's Progress

Re: Parameters [WAS: Main menu puzzle]

2006-02-21T14:30:55Z

Mark Wieder wrote:

>>>
>>>>>on alertStranger "mixmastabilongjeezuscrise!"
>>>>>beep
>>>>>put "wanpelasquashimallbuggerup!" into field "Stupid"
>>>>>end alertStranger
>>>>>
>>>>>What are they telling you?
>>>
>>>>shoodnaswaronlis. aneniway, prameterzdonhakwotz.
>>>
>>>Yahnesclamathingstu. Gon confuzikompila, no?
>
>>Nahdifits endadahstrin, dontink.
>
> Noddahvalli pramitta. Stoptintrax.

Wo! Whaddyaknow. Yoorye!

>>(I just ran all this through babelfish. It comes back the same as it
>>went in.)
>
>
> Garbajin-garbajout!

Storee mylaef.

--
Jacqueline Landman Gay | jacque@...
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-21T14:13:03Z

Jacque-

> Mark Wieder wrote:
>> Jacque-
>>
>>
>>>>on alertStranger "mixmastabilongjeezuscrise!"
>>>>beep
>>>>put "wanpelasquashimallbuggerup!" into field "Stupid"
>>>>end alertStranger
>>>>
>>>>What are they telling you?
>>
>>
>>>shoodnaswaronlis. aneniway, prameterzdonhakwotz.
>>
>>
>> Yahnesclamathingstu. Gon confuzikompila, no?
>>

> Nahdifits endadahstrin, dontink.

Noddahvalli pramitta. Stoptintrax.

> (I just ran all this through babelfish. It comes back the same as it
> went in.)

Garbajin-garbajout!

--
-Mark Wieder
mwieder@...

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T22:34:54Z

Tch tch, I don't think anyone really tried. It's quite easy if you know a bit of pidgin from Papua New Guinea.

mixmastabilongjeezuscrise

mixmasta = mixmaster, a 1950's brand of electric beater for eggs, cream, cakes etc.
bilong = belongs to
jeezuscrise = Jesus Christ

So, it's something coming down from heaven that looks (from below) like a big eggbeater.
A helicopter.

wanpelasquashimallbuggerup

wanpela = one fellow (me, that they are shouting at)
squashim = squash you (me, anyone)
allbuggerup = severe injury or death

So, they are saying there's a helicopter coming down on top of me and I'd better scoot or I'm going to be squashed like a bug.

See, it's all there, english-like, and just like Transcript you just have to know the language and syntax ...;-)

Whoops. Nambawanmeri bilongKen is calling, gotta go

Ken

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T21:10:55Z

You should see what it gives me when I feed it medieval french.

Does Babelfish do Klingon? I know it doesn't do medieval french...

Judy

On Mon, 20 Feb 2006, J. Landman Gay wrote:

> >>>What are they telling you?
> >
> >
> >>shoodnaswaronlis. aneniway, prameterzdonhakwotz.
> >
> >
> > Yahnesclamathingstu. Gon confuzikompila, no?
> >
>
> Nahdifits endadahstrin, dontink.
>
> (I just ran all this through babelfish. It comes back the same as it
> went in.)

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T21:09:28Z

I'm trusting C3PO could translate this?? (yup, you guessed it: kiddies
are just now new devotees to the Jedi religion...)

Judy

On Mon, 20 Feb 2006, Mark Wieder wrote:

> > shoodnaswaronlis. aneniway, prameterzdonhakwotz.
>
> Yahnesclamathingstu. Gon confuzikompila, no?
>

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T21:06:57Z

I'm feeling the odd, irresistable urge to fire up PowerPoint...

blech :-(

;-P

Judy

On Mon, 20 Feb 2006, J. Landman Gay wrote:

> > on alertStranger "mixmastabilongjeezuscrise!"
> > beep
> > put "wanpelasquashimallbuggerup!" into field "Stupid"
> > end alertStranger
> >
> > What are they telling you?
>
> shoodnaswaronlis. aneniway, prameterzdonhakwotz.
>
> --
> Jacqueline Landman Gay | jacque@...
> HyperActive Software | http://www.hyperactivesw.com

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T20:05:41Z

Mark Wieder wrote:

> Jacque-
>
>
>>>on alertStranger "mixmastabilongjeezuscrise!"
>>>beep
>>>put "wanpelasquashimallbuggerup!" into field "Stupid"
>>>end alertStranger
>>>
>>>What are they telling you?
>
>
>>shoodnaswaronlis. aneniway, prameterzdonhakwotz.
>
>
> Yahnesclamathingstu. Gon confuzikompila, no?
>

Nahdifits endadahstrin, dontink.

(I just ran all this through babelfish. It comes back the same as it
went in.)

--
Jacqueline Landman Gay | jacque@...
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T19:51:06Z

Jacque-

>> on alertStranger "mixmastabilongjeezuscrise!"
>> beep
>> put "wanpelasquashimallbuggerup!" into field "Stupid"
>> end alertStranger
>>
>> What are they telling you?

> shoodnaswaronlis. aneniway, prameterzdonhakwotz.

Yahnesclamathingstu. Gon confuzikompila, no?

--
-Mark Wieder
mwieder@...

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T19:45:31Z

Charles-

Monday, February 20, 2006, 5:27:41 PM, you wrote:

Hah! back atcha...

A friend from California was heading down to Lafayette, Louisiana to
attend school. He drove into town and stopped at a gas station to ask
the attendant for directions and it was a full 60 seconds into the
answer before he realized that the guy was speaking English... Gotta
love that Cajun patois..

<sorry - I no longer remember the original topic of this thread>

--
-Mark Wieder
mwieder@...

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T18:14:34Z

Ken Apthorpe wrote:
> I second what Mark says about these sorts of explanations, particularly the
> "Assume nothing" and inclusion of (complete) example scripts for new users.

I found my old notes (from the HyperCard list, but Rev is the same.) It
has a simple example. If I get time, I will combine this with my earlier
response and put it on my web site with my other essays.

****
My favorite analogy is that parameters are baskets. This fits in well
with the HyperCard concept that variables are "containers". Parameters
are just another variable container that catch and hold whatever values
are sent to them. Suppose we have a function called addNumbers like this:

function addNumbers num1,num2
put num1 + num2 into theTotal
return theTotal
end addNumbers

The parameters "num1" and "num2" are like baskets that hold whatever
values the original handler sends. In this case, they each will contain
a number. The special word "return" tells the function to send the
variable "theTotal" back to the handler that asked for the information.
So, this function takes two numbers that are passed to it in the
parameters, adds them together, and sends back a total. Parameter
"baskets" are always filled in first-to-last order; whatever number
arrives first will be placed into the "num1" basket, and whatever number
arrives second will be placed into "num2". It is important that the
order of the values sent are the same as those expected by the receiving
parameters.

Now we can write a handler that uses this function this way:

on myHandler
put 16 into theFirstNumber
put 4 into theSecondNumber
put addNumbers(theFirstNumber,theSecondNumber) into myTotal
end myHandler

This handler will send "16" and "4" to our custom function "addNumbers".
The addNumbers function will catch these two numbers in its parameters.
Since 16 was sent first, it will be received first and placed into the
"num1" basket. The second number, 4, will be placed into the "num2"
basket. The function uses these parameters just as though a script had
issued statements such as "put 4 into num2"; the parameter variables are
automatically filled with the sent values. The function can use these
variables just like any other local variable. This function will add
them together and send back "20". The script "myHandler" will receive
that 20 and put it into the variable "myTotal".

You can have as many parameters as you need. A general rule of thumb is
that passing parameters is prefereable to using globals, except where
many different handlers need to access a value repeatedly. In that case,
a global may be a better solution because it is faster and more
universally available. However, in the above example, it would be silly
to make num1 and num2 into globals; their values will be different each
time the function is called, and it is trivial to pass the values to the
function as needed.

--
Jacqueline Landman Gay | jacque@...
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T17:55:26Z

Ken Apthorpe wrote:

> You are having a dream. You are in a different country, and there's a group
> of locals around you all talking to each other. It's an english-like
> language, you catch individual words but they string them together in a very
> strange way. You stand there gawking and trying to understand. Suddenly
> they all start jumping up and down and waving their arms around and
> jabbering at you. Then they all start running away like crazy. You stand
> there trying to figure out what they were saying. It sounds something like
>
> on alertStranger "mixmastabilongjeezuscrise!"
> beep
> put "wanpelasquashimallbuggerup!" into field "Stupid"
> end alertStranger
>
> What are they telling you?

shoodnaswaronlis. aneniway, prameterzdonhakwotz.

--
Jacqueline Landman Gay | jacque@...
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T17:27:41Z

On Feb 20, 2006, at 8:02 PM, Ken Apthorpe wrote:

> You are having a dream. You are in a different country, and
> there's a group
> of locals around you all talking to each other. It's an english-like
> language, you catch individual words but they string them together
> in a very
> strange way. You stand there gawking and trying to understand.
> Suddenly
> they all start jumping up and down and waving their arms around and
> jabbering at you. Then they all start running away like crazy. You
> stand
> there trying to figure out what they were saying. It sounds
> something like

Hah! I recognize that! from a number of experiences, but one of them
was this (trust me, there's a point, sort of):

I'm a writer at a *very* distinguished (if sparsely populated)
writers' colony, in
the Castle of H--, not far from E--, in the country of S--. (This is
a dozen years
ago.) I'm walking down the back stairs of the castle and come to a
landing
behind the kitchen, where the staff of the castle are sitting around
and talking.
I think they must be talking E-- (or G-- as it's otherwise known).
But when I
pause for a few seconds to savor the sound, which is lovely, I
realize with a
shock that there's a liberal sprinkling of English words, and then
that they are
in fact speaking English, not with the accent they normally use in
speaking to
American and English visitors but with the accent they use among
themselves.

A dream I miss, by the way, and treasure in retrospect. Must be why I
fool around in Transcript . . . Anyway it might account for a lot . . .

Charles

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T17:18:49Z

Ken Apthorpe wrote:

> I second what Mark says about these sorts of explanations, particularly the
> "Assume nothing" and inclusion of (complete) example scripts for new users.
>
> Thanks to the forum I now have a (partially) working menu, thanks to these
> posts I understand parameters more clearly. Transcript may be english-like,
> but it's a different language and has to be learned, so we need plenty of
> examples and analogies like the restaurant. Here's another.
>
> You are having a dream. You are in a different country, and there's a group
> of locals around you all talking to each other. It's an english-like
> language, you catch individual words but they string them together in a very
> strange way. You stand there gawking and trying to understand. Suddenly
> they all start jumping up and down and waving their arms around and
> jabbering at you. Then they all start running away like crazy. You stand
> there trying to figure out what they were saying. It sounds something like
>
> on alertStranger "mixmastabilongjeezuscrise!"
> beep
> put "wanpelasquashimallbuggerup!" into field "Stupid"
> end alertStranger
>
> What are they telling you?

They are telling you:

Once we dreamt we were butterflies,
and woke to find ourselves men.
But now we wonder:
Are we men who dreamt we were butterflies,
or butterflies dreaming we are men?

--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T17:02:22Z

I second what Mark says about these sorts of explanations, particularly the "Assume nothing" and inclusion of (complete) example scripts for new users.

Thanks to the forum I now have a (partially) working menu, thanks to these posts I understand parameters more clearly. Transcript may be english-like, but it's a different language and has to be learned, so we need plenty of examples and analogies like the restaurant. Here's another.

You are having a dream. You are in a different country, and there's a group of locals around you all talking to each other. It's an english-like language, you catch individual words but they string them together in a very strange way. You stand there gawking and trying to understand. Suddenly they all start jumping up and down and waving their arms around and jabbering at you. Then they all start running away like crazy. You stand there trying to figure out what they were saying. It sounds something like

on alertStranger "mixmastabilongjeezuscrise!"
beep
put "wanpelasquashimallbuggerup!" into field "Stupid"
end alertStranger

What are they telling you?

Ken

Re: Parameters [WAS: Main menu puzzle]

2006-02-20T00:54:25Z

>I just ate a hugh meal for my daughters birthday party and really
>can't deal with more food functions right now.

I am well known for my culinary expertise but did not realise how far it
extended, Tom!

/H

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-19T18:31:00Z

On Feb 18, 2006, at 9:43 AM, J. Landman Gay wrote:

> Mark Swindell wrote:
>> Parameters are, to me, the least well-explained and least
>> intuitive aspect of Rev (and programming in general).
>
> You can have any number of parameters declared in a handler:
>
> on myHandler pOne,pTwo,pThree <etc>
> ...
>
> If the engine (or one of your own handlers) passes three parameters
> to this handler, each parameter "basket" will hold one of the items
> that is passed to it.
>
> If more parameter items are passed than you have declared parameter
> "baskets" to hold, the extra ones are not available to your script.
> (There is a way around this using "the params" but that is more
> advanced than we want to talk about here.)
>
> If fewer parameter items are passed to your handler than you have
> "baskets" declared, the extra baskets are empty.
>
> Feel free to ask for clarification, I wrote this very quickly.

This explanation was quite good, as is usual for the source...
thanks :) The tone of this short tutorial is exactly what the doctor
ordered for making Rev comprehensible to new users. The latter part
regarding multiple parameters after declaring the handler is key, as
naming multiple "baskets" and filling them- or not- is the part that
is not at all intuitive. Fleshing this out with a few examples would
be a godsend to the documentation. "Assume nothing" about the new
user is the best route to comprehensible explanations for everyone at
that level... and on up.

Thanks,

Mark
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-19T15:59:48Z

I just ate a hugh meal for my daughters birthday party and really
can't deal with more food functions right now.

Thanks anyway.

Tom ;-)

On Feb 19, 2006, at 2:11 PM, Jim Ault wrote:

>> Mark Swindell wrote:
>>>
>>> Parameters are, to me, the least well-explained and least
>>> intuitive aspect of Rev (and programming in general).
>>
> You order a meal at a restaurant.
> The waitress writes down your order, but does so in a rather cryptic
> fashion.. coffee with cream, a prune danish, scrambled eggs and
> bacon, and a
> glass of water. The parameters you give to her.
>
> The waitress goes back to the short order cook and 'hangs a tag'.
> This slip
> of paper has the parameters the cook needs to process food items
> into the
> meal that matches the order. The cook stops smoking his cigarette
> long
> enough to slide the hot meal onto the shelf for the waitress.
>
> The waitress picks up the luke-warm plate and brings it to your table,
> adding to this, the danish, cold cup of coffee and the water.
> Just what
> you had in mind when you sat down.
>
> Thus, you give the waitress a long list of parameters, she
> processes some of
> them, and passes a few to the short order cook, who does likewise.
>
> Oh, and one other thing.. although you did not specifically request
> this,
> the bill is added to the items you receive because it is implied by
> your
> placing an order.
>
> At home, you have to provide all of the services. At a restaurant,
> there is
> the WaitressFunction, CookFunction, CashierFunction. Depending on
> how the
> owner programmed his restaurant, you get variations in menu,
> service, and
> satisfaction.
>
> Jim Ault
> Las Vegas
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution@...
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

Thomas J McGrath III
3mcgrath@...

Lazy River Software™ - http://www.lazyriversoftware.com

Lazy River Metal Art™ - http://www.lazyriversoftware.com/metal.html

Meeting Wear™ - http://www.cafepress.com/meetingwear

Semantic Compaction Systems - http://www.minspeak.com

SCIconics, LLC - http://www.sciconics.com/sciindex.html

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-19T11:27:13Z

Judy-

Sunday, February 19, 2006, 10:37:36 AM, you wrote:

> Right, again, my argument was less "IF-THENs rule and CASE-SWITCHes suck"
> than IF-THENs are easier to read/learn/are more transparent for
> non/novice-programmers.

I agree that one should learn if/then conditionals before switch/case
structures. But I think one should learn if/thens before elses as
well. You can certainly do any conditional processing without else
statements, but I think it would be unwise to say that it's easier to
code and read code written without else statements.

Switch statements are the equivalent of multiple-choice questions on
an exam. You could code them as many if/then statements, but they lend
themselves naturally (IMO) to switch/case statements.

--
-Mark Wieder
mwieder@...

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parameters [WAS: Main menu puzzle]

2006-02-19T11:11:21Z

> Mark Swindell wrote:
>>
>> Parameters are, to me, the least well-explained and least
>> intuitive aspect of Rev (and programming in general).
>
You order a meal at a restaurant.
The waitress writes down your order, but does so in a rather cryptic
fashion.. coffee with cream, a prune danish, scrambled eggs and bacon, and a
glass of water. The parameters you give to her.

The waitress goes back to the short order cook and 'hangs a tag'. This slip
of paper has the parameters the cook needs to process food items into the
meal that matches the order. The cook stops smoking his cigarette long
enough to slide the hot meal onto the shelf for the waitress.

The waitress picks up the luke-warm plate and brings it to your table,
adding to this, the danish, cold cup of coffee and the water. Just what
you had in mind when you sat down.

Thus, you give the waitress a long list of parameters, she processes some of
them, and passes a few to the short order cook, who does likewise.

Oh, and one other thing.. although you did not specifically request this,
the bill is added to the items you receive because it is implied by your
placing an order.

At home, you have to provide all of the services. At a restaurant, there is
the WaitressFunction, CookFunction, CashierFunction. Depending on how the
owner programmed his restaurant, you get variations in menu, service, and
satisfaction.

Jim Ault
Las Vegas

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: switch/case vs if/then/else

2006-02-19T11:07:48Z

Klaus-

Sunday, February 19, 2006, 8:55:11 AM, you wrote:

> to use the engines syntax: bad case :-)

Thanks for the correction. Should have waited until I was fully awake
before starting to type...

--
-Mark Wieder
mwieder@...

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-19T10:37:36Z

Mark,

Right, again, my argument was less "IF-THENs rule and CASE-SWITCHes suck"
than IF-THENs are easier to read/learn/are more transparent for
non/novice-programmers.

Judy

On Sun, 19 Feb 2006, Mark Wieder wrote:

> Judy-
>
> Your example isn't a reasonable candidate for a switch/case construct
> because the conditionals aren't at the same level. Instead your ifs
> are nested within each other, and that's an example of where and
> if/then/else construct is much more readable. There's no reason to
> convert that.

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Main menu puzzle, Klaus

2006-02-19T10:18:41Z

Show it to a non-programmer/novice programmer and ask him/her the same
question. I suspect the answer will be very different.

Again, my argument is not that if-thens are superior from a
programming/logic standpoint but rather that they are more comprehensible
to normal humans who are not programmers.

And, hence, when used, they make Rev more approachable to that particular
audience (which, after all, is less likely to be biased against Rev
because it doesn't have its provenance in Redmond, isn't what "everybody"
uses, etc.).

Judy

On Sun, 19 Feb 2006, Stephen Barncard wrote:

> and this isn't cleaner? LOOK - a whole bunch of if's and thens don't
> have to be repeated over and over.
>
> on menupick varMenuItemSelected
> SWITCH varMenuItemSelected
> CASE "Cut"
> SubCut
> break
> CASE "Copy"
> SubCopy
> break
> CASE "Paste"
> SubPaste
> break
> CASE "Undo"
> SubUndo
> break
> CASE "Word Wrap"
> SubWordWrap
> break
> DEFAULT
> --
> END SWITCH
> end menupick

Re: switch/case vs if/then/else

2006-02-19T08:55:11Z

Hi Mark,

> Stephen-
>
> ...
> 3. If I have a list of targets that I will probably want to expand
> then that's a candidate for a switch statement.
>
> switch itemToTest
> case
> "sloth"
> "envy"
> "gluttony"
> put "sin" into whatIsIt
> break
> default
> put "virtue" into whatIsIt
> end switch

to use the engines syntax: bad case :-)

We have to write:

...
switch itemToTest
case "sloth"
case "envy"
case "gluttony"
put "sin" into whatIsIt
...

> -Mark Wieder
> mwieder@...

Regards

Klaus Major
klaus@...
http://www.major-k.de

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-19T08:52:55Z

Judy-

Saturday, February 18, 2006, 9:27:39 PM, you wrote:

> Yes, but do you think in these terms in day-to-day life?

Your example isn't a reasonable candidate for a switch/case construct
because the conditionals aren't at the same level. Instead your ifs
are nested within each other, and that's an example of where and
if/then/else construct is much more readable. There's no reason to
convert that.

Where the switch statement comes into its own is where you have
multiple choices at the same level:

IF the paycheck arrives tomorrow THEN
switch tomorrow
case Saturday
case Sunday
Write the rent check two days later
break
default
Write the rent check the day after
end switch
END IF

> And, even if you do, it's still not how normal humans describe
> cause-and-effect phenomena in non-programming situations.

Actually, it is. When you come across "if tomorrow is a weekend day
THEN" you don't process it literally - your brain converts "weekend
day" into "let's see - is this a Saturday or a Sunday or something
else" and then returns to inline processing. So your brain is really
doing the switch/case process for you, expanding the shorthand
"weekend" into what that corresponds to, eventually returning a
boolean value to you and giving you the goahead to write the check.

Hope your check clears <g>

--
-Mark Wieder
mwieder@...

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

switch/case vs if/then/else

2006-02-19T08:40:30Z

Stephen-

I have three rules of thumb for selecting switch/case constructs vs
if/then/else constructs (or at least three that I can think of off the
top of my head):

1. As Rob Cozens has pointed out, if I have more than two choices then
I will probably convert to a switch statement.

switch itemToTest
case 2
case 3
case 4
answer "it's a" && itemToTest
break
default
answer "it's unknown"
end switch

2. If I have a few exceptions to a regular rule then I will make a
case statement with a break and put the rule in the default handler.

switch itemToTest
case NOPPMTooHigh
case HCLPPMTooHigh
put "failed" into tSmogTestResult
break
default
put "passed" into tSmogTestResult
end switch

3. If I have a list of targets that I will probably want to expand
then that's a candidate for a switch statement.

switch itemToTest
case
"sloth"
"envy"
"gluttony"
put "sin" into whatIsIt
break
default
put "virtue" into whatIsIt
end switch

--
-Mark Wieder
mwieder@...

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-19T08:07:26Z

Judy, et al:

> Yes, but do you think in these terms in day-to-day life?
>
> IF I have the paycheck in-hand THEN
> it will clear the bank in 2 days
> I can write the rent check tomorrow and it will clear at the same
> time
> END IF
>

I will grant you:

(a) As one who has used case statements for years, I may not appreciate
the learning curve for non-programmers, and

(b) Where ifs and switches can be used interchangeably, the choice is
basically one of preference.

Note the "Where" in item (b). Switches and ifs are not interchangeable
in all syntax. Your full example of ifs and nested ifs is _not_ an
example of syntax that lends itself to switches, and thus is not (IMFO)
pertinent to this discussion.

Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-19T02:08:23Z

On 19 Feb 2006, at 05:27, Judy Perry wrote:

> Yes, but do you think in these terms in day-to-day life?

Well, yes.

When the doorbell rings, I don't think like this:

if it's the postman
I'll say good morning
if it's the taxman
I'll get my gun
if it's the neighbor
etc,

Instead, I'm more likely to think "who could that be", and compile a
list like this ...

postman
milkman
delivery man

taxman
police
bailiff
mother-in-law

daughter's boyfriend

son's girlfriend's father

...which lends itself to a switch/case structure.

So depending on the situation, both approaches can seem quite natural.

Cheers
Dave
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Main menu puzzle, Klaus

2006-02-19T02:06:28Z

and this isn't cleaner? LOOK - a whole bunch of if's and thens don't
have to be repeated over and over.

on menupick varMenuItemSelected
SWITCH varMenuItemSelected
CASE "Cut"
SubCut
break
CASE "Copy"
SubCopy
break
CASE "Paste"
SubPaste
break
CASE "Undo"
SubUndo
break
CASE "Word Wrap"
SubWordWrap
break
DEFAULT
--
END SWITCH
end menupick

I find SWITCH/CASE statements to be quite elegant, actually, and you
can do things in fewer lines than an IF statement will do in many
situations. Execution goes straight down, and breaks are the stoppers!

SWITCH colors
CASE "green"
CASE "blue"
CASE "yellow"
CASE "orange"
put "color set one"
break
CASE "brown"
CASE "red"
CASE "purple"
put "color set two"
break
DEFAULT
put "not from either set"
END SWITCH

looks pretty linear to me... a lot easier than repetitive ORs or a
lot of if-thens.

sqb

>And I think another thing, a bit odd I'm sure, but I find the Case
>statements to be... well... Ugly for some reason. Just looking at
>code for a Case statement doesn't seem to flow naturally in my mind,
>but an equivalent If statement does. Don't ask me why! Could be
>that I'm just a seriously odd fellow ;-)
>
>-Garrett
>P.S. BOYCOTT CASE STATEMENTS! IF STATEMENTS ROCK!

--
stephen barncard
s a n f r a n c i s c o
- - - - - - - - - - - -
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-19T00:36:11Z

Hi Judy,

> For the novice/non-programmer, there IS no difference between
> how they think in everyday terms and how they "read code".

I don't disagree with the psychology, though it would seem
to me that learning such issues as case statements early on
will not only advance a novice, but make their code more
readable as they progress from novice to a more advanced
level. In fact the satisfaction of writing something that
is elegant (which if/then/else is barely) is guaranteed to
be fruitful and rewarding.

Scott

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Main menu puzzle, Klaus

2006-02-18T23:59:33Z

On Sat, 18 Feb 2006 16:56:32 -0600, "J. Landman Gay"
<jacque@...> wrote:

>
>> And to this day, I just don't understand the whole purpose of the
>> Case
>> statement..... Still don't even after reading a few of the
>> replies to
>> this thread.
>>
>
> I prefer switch/case statements when there are many options a
> script has
> to deal with. I'll admit though that there is little difference
> between
> switch/case and if/then constructs when the choices are
> straightforward.

[snip]

> The above construction is easier for me to read and executes faster
> in a
> script.

Yes, as a programmer who (years ago) used to program at a low level
(including some compilers), I feel that there's at least the
possibility that a long case statement can be compiled in such a way
as to run faster than a lot of 'if' statements. I sense some kind of
lookup table being used. Of course this may not be the case at all,
but at least it's faster **in principle**. I admit this is a very
geeky way of looking at it.

OTOH I agree with all the other people who said a case (switch)
statement seems clearer than the 'if' construction for long multiple-
choice logic. I am not at all nostalgic for my low-level days and
feel thankful every day for the clarity and power of xTalks.

Just my 2 Eurocents

Graham

------------------------------------------------------------------------
---
Graham Samuel / The Living Fossil Co. / UK and France

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-18T22:27:28Z

Yes, indeed.

It is the difference between a seasoned programmer and a
novice/non-programmer. The former is able to see the whole as a pattern
that is already understood, allowing one to focus on whatever the problem
is at hand.

The latter, however, has to parse each and every word to look-up what it
is/means/does, because the pattern/metaphor/language is not already
understood.

For the novice/non-programmer, there IS no difference between how they
think in everyday terms and how they "read code".

Judy

On Sun, 19 Feb 2006, Scott Kane wrote:

> > Yes, but do you think in these terms in day-to-day life?
>
> No. But (apart from some languages that optimize due to the
> use of case statements - not sure if Rev does) it is a heck
> of a lot easier to read code later in a case statement (in
> Rev a Switch) than it is to read if/then/else in complex
> code structures.

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-18T21:42:22Z

> Yes, but do you think in these terms in day-to-day life?

No. But (apart from some languages that optimize due to the
use of case statements - not sure if Rev does) it is a heck
of a lot easier to read code later in a case statement (in
Rev a Switch) than it is to read if/then/else in complex
code structures.

Scott

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Main menu puzzle, Klaus

2006-02-18T21:41:16Z

Judy,

"Guys" and "Gals", (sorry). ;-)

Also, I hope you are feeling better.

I know if then's made sense to me when I first started and I probably
would never have thought up a switch statement. But I guess once I
saw how it worked I didn't find it to be as some have said "Machine-
speak" but rather as sensible. I mean as a list of choices that the
item could be and when the right choice is found then 'break' out of
the statement completely.

I was curious, and thanks for your response, why I didn't feel like
others did about it.

To be fair though I would write the case as compared to your if then
like this:

switch mailArrived
case "I got paid"
pay the rent
break (stop here)
case " I didn't get paid"
get ready to move
break
end switch

But I guess I am starting to see by the way you wrote them how it
would be 'more' english like with the if-then's for a simple statement.

Since I know how simple adding different cases to test for is with a
switch, I would use the if-then's for simple two or three line tests
but I would use the switch-case for more than that and also if I was
building case scenarios along the way. They are quite easy to add to.

Thanks for sharing and sorry again about the lack of gals in my prev
email.

Tom

On Feb 19, 2006, at 12:19 AM, Judy Perry wrote:

> Thomas,
>
> Well, as a "gal" as opposed to a "guy", I'll submit the following:
>
> In everyday/non-programming life, we just don't think in terms of case
> statements; we think in terms of if-thens:
>
> case paycheckArrivesInMail
> payRent
> switch
> case paycheckNotInMail
> waitToBeEvicted
> switch
> ...
>
> I dunno... maybe y'all do... but I think thus:
>
> IF I get paid THEN
> I can pay the rent
> ELSE I risk getting an eviction notice
>
> If-Then is just another way to express cause and effect, one of the
> earliest things we learn as humans (also known as the permanency
> effect:
> that irritating thing babies do when repeatedly dropping things
> from their
> view, only to be delighted when you, as predicted, return the items to
> them).
>
> Case statements may well be more elegant, take fewer
> lines/characters/whatever... but it's machine-speak, not human-
> speak. If
> I wanted machine-speak, I'd learn to program in octyl...
>
> Judy
>
> On Sat, 18 Feb 2006, Thomas McGrath III wrote:
>
>> Hey guys,
>>
>> I don't understand why you guys don't like switch case statements?
>> Really. I am trying to remember the first time I saw and used them
>> back in Supercard. I remember thinking they were more difficult to
>> write but once I did they seemed to do a lot more than if then's or
>> at least with fewer words.
>> I am curious to maybe what I saw that others didn't or what others
>> see (and don't like) that I didn't see.
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution@...
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Switch versus if/then/else ( was: Main menu puzzle, Klaus)

2006-02-18T21:27:39Z

Yes, but do you think in these terms in day-to-day life?

IF I have the paycheck in-hand THEN
it will clear the bank in 2 days
I can write the rent check tomorrow and it will clear at the same time
END IF

IF the paycheck arrives tomorrow THEN
IF tomorrow is not a weekend day THEN
I can write the rent check the day after and be late but it will clear
ELSE if tomorrow is a weekend day THEN
I will write the rent check two days later, be late, pay the late fee
and the rent check will still clear
END IF

ELSE I'm screwed.

(Am I the only person on list who has to worry about when checks clear???)

Oh, and in any case, if you don't already know case statements and
switches, THEY JUST DON'T MAKE MORE SENSE than if-thens!

And, even if you do, it's still not how normal humans describe
cause-and-effect phenomena in non-programming situations.

Judy

On Sat, 18 Feb 2006, Eric Chatonet wrote:

> Hi everyone,
>
> Does switch is able to bring more flexibility and readability than if/
> then/else?
> The answer is yes.

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Main menu puzzle, Klaus

2006-02-18T21:19:32Z

Thomas,

Well, as a "gal" as opposed to a "guy", I'll submit the following:

In everyday/non-programming life, we just don't think in terms of case
statements; we think in terms of if-thens:

case paycheckArrivesInMail
payRent
switch
case paycheckNotInMail
waitToBeEvicted
switch
...

I dunno... maybe y'all do... but I think thus:

IF I get paid THEN
I can pay the rent
ELSE I risk getting an eviction notice

If-Then is just another way to express cause and effect, one of the
earliest things we learn as humans (also known as the permanency effect:
that irritating thing babies do when repeatedly dropping things from their
view, only to be delighted when you, as predicted, return the items to
them).

Case statements may well be more elegant, take fewer
lines/characters/whatever... but it's machine-speak, not human-speak. If
I wanted machine-speak, I'd learn to program in octyl...

Judy

On Sat, 18 Feb 2006, Thomas McGrath III wrote:

> Hey guys,
>
> I don't understand why you guys don't like switch case statements?
> Really. I am trying to remember the first time I saw and used them
> back in Supercard. I remember thinking they were more difficult to
> write but once I did they seemed to do a lot more than if then's or
> at least with fewer words.
> I am curious to maybe what I saw that others didn't or what others
> see (and don't like) that I didn't see.

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution