Using 'for each' to modify a container

[Jim Ault]

Hello, Jacque,

On 10/11/06 8:14 PM, "J. Landman Gay" <jacque at hyperactivesw.com> wrote:

> Bill Marriott wrote:
> 
>> And I'm *really* concerned about the second part of your report
>> 
>>> Further, I don't reuse the name 'thisLine' in the next instance of a
>>> repeat
>>> for each loop in the *same handler*, but change the name to avoid
>>> conflict,
>>> such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable
>>> results
>>> occasionally.
>> 
>> Surely THAT is a definite bug?! Have other people experienced this? Are you
>> able to reproduce it? Is there a bug on it already filed? I do this all the
>> time and I'd have to update a lot of code to fix it.
> 
> For what it's worth, I do it all the time too and have never had a
> problem. I think maybe the original poster was just being cautious.
> 
I am the original poster, and I will explain a bit more.  I have several
apps that do some intense data parsing, error checks, and reformatting.   At
some point during the development a few months ago I was trying to chase a
set of bugs in a handler that were very elusive.

My standard repeat form evolved to:

repeat for each line LNN in varList
  put item 1 to 2 of LNN & cr after newVarList
end repeat
delete char -1 of newVarList

and, like you, reused my choice of LNN.  Cool beans.  However...in one long
handler...

Using Variable Watcher and some test variables, I saw 'LNN' change the way
you would expect, then later, strangely, it held some garbage characters,
and thus the bug(s).  The failure was not always the same, but it did fail
before the end of the process.  By not reusing LNN each time, the problem
has not returned.

My current system is to use LNN1, LNN2, LNN3, etc.  The reason I use all
caps is to remind me not to change the variable,
but rather recast ( eg. get LNN) so I could change the value.

You are right about 'just being cautious'.  I have too much to accomplish to
go through the 'strange debug' again.

Jim Ault
Las Vegas