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.
from:
http://blogs.msdn.com/alfredth/archive/2007/03/19/programming-proverbs-12.aspx
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
breaking dykes).
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
variable.
A voice for the mainstream user, not the specialist
Björnke
--
stephen barncard
s a n f r a n c i s c o
- - - - - - - - - - - -
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
