On Thursday 30 July 2009, Mike Walter wrote:
> Harry,
>
> I *like* it when people keep pushing a question until a myth has been
> fully explored.
Oh, my. Well, if we must explore it fully, I have to excerpt a
snippet from a Rexx course I recently taught, illustrating how the use
of "not quite reserved" keywords as variable names *can* trip you up.
It typically happens when one is dynamically building a string to be
interpreted.
The original setup emulated the old PL/I game of coding things like:
IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;
which came to mind when I saw a piece of code where "if" had been
thoughtlessly used as a variable containing the name of a network
interface (NIC). For brevity, we'll reduce the setup to the first line
below.
/* Setup the gag... */
if = "THEN"; then = "ELSE"; else = "IF";
/* ...and some variables... */
days = 365
cond = "days < 366"
yesaction = "say 'not a leap year';"
noaction = "say 'leap year';"
/* ...and a couple of strings to interpret. */
/* This string shields keywords from variable substitution. */
cmd = "IF" cond "THEN" yesaction "ELSE" noaction
/* This one doesn't. */
tmpjunk = IF cond THEN yesaction ELSE noaction
/* Now try this - it will work properly. */
say "We are executing"; say " '" || cmd || "'";
say " -- twice. It will work both times."
say "Try #1 - open code:"
IF days < 366 THEN say 'not a leap year'; ELSE say 'leap year';
say "Try #2 - interpreted, but with carefully protected keywords."
interpret cmd
/* Now try this - it will behave rather badly. */
say "Now we are executing"; say " '" || tmpjunk || "'";
say "The result will not be pretty."
say "Try #3 - interpreted, keywords not protected."
interpret tmpjunk
So, although Rexx is perfectly capable of recognizing the context of
a keyword under ordinary circumstances, avoiding the use of keywords as
variable names is more than a matter of aesthetics. It's pretty easy to
shoot yourself in the foot if you believe you can't do so.
Cheers,
Bob
--
Bob Woodside
Woodsway Consulting, Inc.
http://www.woodsway.com