dunbarx wrote: ↑Mon Jun 11, 2018 4:08 pm
Whenever you need a collection of variables whose names cannot be known in advance, an array is the simplest and fastest solution.
Clearly. My point is that "do" and its extra evaluation still comprise an invaluable tool in LC.
It is indeed useful, but mostly for those circumstances where we do not already have a purpose-built language element designed specifically for the task at hand. In some ways, "do" is the hammer that risks making everything look like a nail.
For example, this will execute just fine:
Of course your reaction would rightly be that using "do" there is unnecessary, since the "go" command works quite well without it.
The same is true of many other uses of "do" where built-in syntax has been added as a direct means of handling a task.
For those raised with HyperCard some 25 years ago, "do" was more frequently used because HyperTalk was a much more limited language. Among those limitations was that it had no arrays, so we developed habits of working around those limitations by whatever means we could find. We also had no custom properties, and had to come up with clever workarounds of using hidden fields, and we had no color so we had to get used to using an external that painted color overlays our our monochrome objects. It was a very different environment; a lot of fun in its day, but it's nice to have the rich scope of options we have today in LC.
Today's learners are in a world in which nearly every language they've seen supports arrays, which were added to this family of languages in LiveCode for cases like this. If we come across one I would be happy to learn from it.
Do is
very valuable when arbitrary execution is needed and the goal is not already supported more directly.
But for those unaccustomed to it, its concatenation requirements and meta-execution nature arguably make it a bigger cognitive load than using purpose-built arrays for things like collections of variable names, it's measurably much slower to execute, and in Internet applications introduces one more point of potential injection that we need to think very carefully about.
Where no direct means is available, "do" is a godsend. But where we have a direct means, I've seen no cases where it offers a benefit beyond those already provided by alternate syntax designed for the task.