. 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 <[email protected]>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 > [email protected] > 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> > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
