initialize an static, local, script-wide variable to empty

[Richard Gaskin]

erik hansen wrote:

> --- Richard Gaskin <ambassador at fourthworld.com>
> wrote:
> 
>> What was the emprical method used?
> i repeated this handler:
> 
> global sHolder
> on e
> put sHolder into msg
> # sHolder was always empty
> put 12 into sHolder
> end e
> # the 12 did not stay in sHolder after <end e>

Change the declaration from "global" to "local" and you should be fine.
 
> just using the Debugger also has some weird side
> affects.

What have you found?

>> I tend to use them in two circumstances:
>> 
>> - where I might have used globals but want to
>> avoid name-space collisions
>> (great for utilities and plugins where you have
>> no control over the name space)
> 
> "name space" is a new expression for me. ???

It's geekspeak for "the range of all possible names".

> after all this, i am back to declaring
> temporary/in-handler locals. a trade off
> between extra text versus having all variables
> declared at the beginning of each handler.
> using handler + parameters to pass info
> involves the same kind of trade off.

When you get the hang of using script-local vars, they serve a different
olace from globals and parameters, and are useful in their own right, worth
becoming familiar with.

If you've been declaring them with "global" I can understand the confusion,
as theyt would then act as common local vars (the "global" declaration is
ignored outside of handlers).

 
> using the script/static approach generated
> some very strange results:
> 
> local sHolder = empty # no quotes
> put the actual "e-m-p-t-y" string into sHolder
> in the first handler that ran
> the only instance i have ever seen where empty
> did not resolve to just that.

If you post the actual code we can identify the problem.

> there was a loop where:
> 
> local i # outside any handlers
> on xxx
>  repeat with i = 14 to 18
>   # on the first pass (i = 14) fine,
>   # on the second pass (i = 5)
>   put goGetum() after sHolder
>  end repeat
> end xxx
> 
> function goGetum
>  repeat with i = 1 to 5
>   doSomething
>  end repeat
> end goGetum 
> 
> this is the only case in my experience where
> repeat with i = 
> did not follow orders

This may be a case of the propgram doing what you told it rather than what
you intended.  :)

In the first loop, you initialize i to contain 14, but then in its repeat
loop you cann another handler which uses the same variable to count from 1
to 5, so when it returns i contains the last value set: 5.

> take home thought:
> use script/static locals very carefully

Or maybe the take home thought is simply:
If you need two different repeat loops to count independently, you two
different variables as the counter.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc