For Each Anomaly
stephenREVOLUTION at barncard.com
Wed Jun 20 02:28:42 CDT 2007
You shouldn't be shocked by this. In many
languages I've worked with (including HC and
BASIC), it's not usually cool to change any loop
variable directly, but instead one must work from
a copy. Pretty standard practice for years. One
can easily use another variable instead. To you
it's just a variable, to Rev it's a 'thingie'
that needs to be managed. When you 'go behind a
language's back' strange stuff can happen.
Don't touch loop variables. End of story.
Programming Proverbs 12: Leave loop variables alone
Another way of expressing this is to use loop as
if they were read-only constants. Loop variables
should be initialized and changed only in the
loop statement itself.
The problem with doing it anywhere else is that
it is too easy to either make the modification
incorrectly or to do so in the wrong place.
Changing loop variables outside the loop
statement also makes programs more difficult to
debug and to modify. debugging gets complicated
when one has to search for the locations where a
variable is modified. Modifications to loop
variables should only happen in one place to keep
it simple. By treating loop variables as
read-only and never modifying them inside the
loop the debugging process is simplified at least
a little. Sometimes every little bit helps.
A lot of beginners think that once they are done
with a program that it will never be revisited.
That may be true for programs that are created as
class assignments but it is generally not the
case for most any other programs.
Students should always write their programs as if
someone else will later come along to either
maintain or enhance it. It's a good habit to get
into as it forces better design practices. When
it comes to maintaining or more importantly
adding code to a loop the last thing you want is
problems figuring out where and how the loop
control variable is modified.
Keeping it simple (like leaving loop variables
alone) is a good idea and a good habit to teach.
>This is looking completely wrong at the issue. A
>variable should be changeable, it's in the
>definition of the name. If a variable is not
>changeable it should be renamed to "constant" or
>maybe "don'ttouchthisthingy". If a user changes
>a variable, it should not throw errors, or
>behave unexpected. Most people have enough
>problems with expected behaviour, no need to
>complicate the matter.
>Adding description for every unexpected
>behaviour is like trying to prevent a breach in
>a dyke by explaining to the water that it should
>go somewhere else. If the language would behave
>as expected, there would be less airquote & bug
>& airquote reports immediately (and less
>Basically any confusion for a user should be an
>opportunity to increase the reliability of the
>user experience. Scrutinising a user or putting
>him down for being confused is a sure way to
>have one user less.
>Therefore, Rev should make the labelVariable
>changeable whenever any user wants, i'm pretty
>sure that'd be not a problem to do for them (as
>it worked in earlier versions). Allowing changes
>to the container variable is probably much
>harder, but I'm sure something could be done
>about that too.
>I also would like to add, that I often change
>label variables in repeat for each loops, and
>have had never any errors thrown because of it
>(or unexpected results). I did however get
>unexpected results from changing the container
>A voice for the mainstream user, not the specialist
s a n f r a n c i s c o
- - - - - - - - - - - -
More information about the use-livecode