"do" statements and value function

[Mike Bonner]

. Think the OP was asking about what do can do vs the other mentioned
options, so I was pointing out something do could do with its vudu, but I'd
use arrays too, just like you, oops gotta run, I'm overdue.

On Mon, Jun 20, 2011 at 8:28 AM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

> 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<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<http://LiveCodejournal.com/blog.irv>
>
> ______________________________**_________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>