14.4. Number, String, and Date Coercions

An integer may be coerced to a real .

A real (within in the integer range) may be coerced to an integer; it is rounded to the nearest integer. This was a new feature starting in Panther; in earlier versions of AppleScript, a real could be coerced to an integer only if it was an integer (that is, it had no fractional part). The old behavior is still present in repeat with (see Chapter 19) and, as you'll see in a moment, in coercion from a string (I regard this as a bug).

Observe that AppleScript's real-to-integer coercion rule is not like that of other computer languages you may know, such as in C, where the fractional part is thrown away. To throw away the fractional part of x, say x div 1 (see Chapter 15). The round scripting addition command can also help here (see "Numbers and Dates" in Chapter 21), as it can be used to dictate the desired rounding behavior.

A number may be coerced to a string.

A string may be coerced to a number, provided that the string looks like a literal number; whitespace will be ignored, but nothing else will be. So for example "1a" can't be coerced to a number. But the empty string, or a string consisting solely of whitespace, will be coerced to 0.

Distinguish between the classes integer and real, on the one hand, and number on the other. A string may be coerced to a real, provided that the string looks like a number. A string may be coerced to an integer, though, only if the string looks like an integer value:

"1.1" as real -- 1.1
"1" as real -- 1.0
"1.0" as integer -- 1
"1.1" as integer -- error: Can't make "1.1" into type integer

But a string that looks like an integer or a real can be coerced to a number, and it will be coerced to whichever datatype is appropriateinteger or real. This is nice because it saves you from having to worry about which is appropriate.

class 
 of ("1" as number) -- integer 

class of ("1.1" as number) -- real 

Thus we have a workaround for the problem of coercing a string representing a real to an integer:

"1.1" as number as integer -- 1

However, number cannot be used in every situation where a numeric coercion is possible. For example, TRue as integer is legal, but true as number is not. I regard this as a bug.

A version can be coerced to a real; this coercion is useful for ascertaining that the version of something is at least as high (or low) as some requirement. However, with Tiger, the algorithm has changed. Previously, version 1.9.3 (for example) would coerce to 1.93. Now, a version such as 1.10 is possible; this would coerce to 1.1, which is less than 1.93. Therefore, starting in Tiger, two digits are used for each section of the version, and version 1.10.3 now coerces to 1.1003. But most applications supply their version as a string property anyway, which can't be coerced to a real:

tell application "Finder"
    set v to (get version)
end tell
v as real -- error: Can't make "10.4.2" into type real

A class or constant may be coerced to a string. For example:

string as string -- "string"
italic as string -- "italic"

However, if you allow a class to be coerced to a string by some command, you may get a different result. Here, the display dialog command turns the class into its four-letter code:

display dialog string -- TEXT

A date may be coerced to a string; this is the same string that appears in the literal date specifier after compilation or in a result.

A string may be used to form a date specifier, but it cannot be coerced to a date.

A month may be coerced to a string (because it is a class). A month may also be coerced to an integer; this was a new feature in Panther. An integer cannot be coerced to a month, but it can be used to set a date's month property (new in Tiger). A weekday can be coerced to an integer (new in Tiger): Sunday is 1.

A string, Unicode text , and styled text may be coerced to one another. When coercing to a string, you can say as text instead of as string. This way of talking is confusing, though, because the class of the result is still string, and text is actually the name of a completely different class (string is 'TEXT', text is 'ctxt').

In the past, you could not rely on all commands, especially in scripting additions, to coerce a parameter between Unicode text and string . Thus something like this would mysteriously fail:

tell application "Finder"
    say (get name of disk 1)
    -- error: Finder got an error: "feathers" doesn't understand the say message
end

The problem, although you'd never know it from the error message, is that say couldn't take Unicode text as a parameter. In Tiger, this problem is generally fixed.