"do" statements and value function

[Richard Gaskin]

Mike Bonner wrote:

> Say you have an unspecified number of "things" you want to put into their
> own variables (yeah, I know, use an array, but for example purposes arrays
> don't exist)
>
> So, if you want to put each line of a random number of lines into its very
> own variable, this is where the example I cited comes in.
>
> *put 1 into tcounter*
> *repeat for each line theLine in theData*
> *do "put theData into myVar" & i*
> *add 1 to tcounter*
> *end repeat*
> *
> *
> This will put the first line into myVar1 line 2 into myVar2 etc on down the
> line.

I think this may have been covered before but catching up on this thread 
I couldn't find the post:

Why not use an array?

When you need a set of variables whose quantity of elements and/or 
element names can't be known in advance, arrays are a perfect fit:

   put 1 into tCounter
   repeat for each line tLine in tData
      put tData into myVar[tCounter]
      add 1 to tCounter
   end repeat

Using "do" and "value" can be very powerful for many tasks, but relative 
to arrays they carry a cost to both performance and ease of debugging.

With most scripts, tokens can be compiled in advance of execution.  But 
with "do", "value", "send", and "dispatch", those expressions need to be 
evaluated at runtime.  Used once the difference can be minor, since it's 
a fraction of a millisecond.  But in a lengthy repeat loop it can add up 
and potentially become noticeable.*

The hash lookup used in arrays is so blindingly fast that, coupled with 
the ease of being able to do things like get the keys of the array to 
discover the number of elements created, the benefits are overwhelmingly 
favorable compared to "do".



* I'll admit I'm a bit of a "microsecond weenie" (someone overly 
concerned about performance), but I feel it's often worthwhile adopting 
good scripting habits that favor performance because the clock cycles 
saved may allow an app to add new features down the road which might 
otherwise be prohibitive, like real-time update of displays.

If you're a bit of a "microsecond weenie" yourself, this outline on 
benchmarking may be of interest:
<http://livecodejournal.com/tutorials/benchmarking-revtalk.html>

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv