Section 5.2. Result

5.2. Result

At runtime, a line of AppleScript code that actually executes an expressionthat is, it isn't blank, a comment, or mere flow control (looping and branching)will usually generate a result . This result is some sort of value; the particular value depends upon what the line does.

The line need not be a command; any valid AppleScript expression constitutes a valid line, even if it does nothing. For example, this is a valid line of AppleScript code, and it has a value (can you guess what it is?):

 5

A line's result may be captured in two ways: explicitly or implicitly. The next two sections describe them both. As you'll see, my view is that in general you should not make any use of the fact that a line of code has a result. However, the exception proves the rule, so I will also suggest that in just one situation (while developing your code) capturing a line's value implicitly is useful.

5.2.1. Explicit Result

The result of a line after it is executed may be captured explicitly by using the keyword result in the next line that is executed. For example:

 5 display dialog result  5

One sees this technique used typically after fetching a value in a context of interapplication communication. For example, this is a fairly common style of coding:

 tell application "Finder"     get the name of every folder end tell set L to the result

Here's another example:

 tell application "Finder"     count folders end tell set c to the result

Why is this technique so common? It may be a habit derived from HyperTalk , where this was a standard idiom. Or people may feel that a line is more legible and understandable if it consists of a single command. Nonetheless, this technique is unnecessary. You can execute a command and capture its result in the same line by nesting commands, as I mentioned in the previous section:

 tell application "Finder"     set L to (get the name of every folder)     set c to count folders end tell

What's more, using result is, I would argue, a downright bad idea. To use result is to be dependent upon AppleScript's rules about what a statement's result is. But you may not know these rules as clearly as you suppose. Your intuitions can lead you astray. For example:

 set L to {"Mannie", "Moe"} set end of L to "Jack"

After these two lines, L is {"Mannie", "Moe", "Jack"}, but result is "Jack". If you were expecting result to be the same as L, you'll be wrong, and code that depends upon this assumption won't work. That's a simple example; for more complicated code, the chances increase that you may be mistaken about what result represents. Why risk this sort of mistake when in fact it is never necessary to use result in the first place?

Also, result is volatile. It changes after the execution of every expression. If you get into the bad habit of not capturing values when they are generated, because you intend to pick them up later using result, you are just asking for trouble. You might, in the course of further developing your code, insert a line between the line where the value is generated and the line where you pick it up as result; the value of result will then be different from what you expect. This kind of mistake is very difficult to debug. So I recommend that you not get into the habit of using result at all.

5.2.2. Implicit Result

The result of a line's execution is captured implicitly if it is the last line executed in a handler or script. This means that in theory there is no need to return a value explicitly (using the keyword return) from a handler or script. For example, instead of this:

 on add(x, y)     return x + y end add display dialog add(1, 2)

it is possible to say this:

 on add(x, y)     x + y end add display dialog add(1, 2)

This technique suffers from the same drawbacks as using result. The keyword return has two great advantages: you know exactly what you're returning (because that's the value of whatever follows the word return) and when you're returning it (because the handler exits the moment return is encountered). To rely on an implicit result is to know neither of these things. A line's result, as we've seen, may not be what you think it is. And the value returned by a handler or script is not the value of its physical last line, but rather the value of whatever line happens to be executed last; where there is flow control (loops and branches), you might not know what line this will be.

However, I do make use of the implicit result in one particular contextwhen developing and testing a script. If a script does not explicitly return a result (using return), a script editor application always displays the implicit result after execution. To check whether the script is working as expected, I specify the value whose implicit result I want to see:

 on add(x, y)     x + y end add set z to add(1, 2) z

The last line here causes the value of z to be displayed after the script executes; thus, I can check that z is taking on the expected value. The last line is a way of saying return z, only better. To see why, let's suppose you return the value of z explicitly, like this:

 on add(x, y)     x + y end add set z to add(1, 2) return z

You now proceed with developing the script, appending additional code after this snippet, and are very surprised when it doesn't work as expected. The reason is that you've accidentally left this line in the script:

 return z

When that line is encountered, execution terminates (because that's part of what return means); the code that follows it is never executed. You will probably be confused as to what's gone wrong; in fact, you might continue developing your script, not realizing that anything has gone wrong, and imagining that the result shown by your script editor is the implicit result from a later line! By contrast, the nice thing about this expression:

 z

is that it has no effect at all on the behavior of your script, even if further code is subsequently appended.