Apple

I have to echo previous posters' opinions that hiding the details from scripters does them a disservice, especially when the hiding of details breaks down when presented with the simplest of compound expressions. The recent discussion of implied 'get' events is a prime example.

Here's another bit of AppleScript deception that bit me recently. AppleScript 2.0 has eliminated the disparate string data types (string, Unicode text, international text, etc.) and gone to Unicode-only strings. Bravo! To provide some level of backward compatibility, all of the legacy string data types are viewed as synonymous. In other words, on AppleScript 2.0:

set theString to "string"

set theClass to (class of theString) --> 'text'

set theResult to (theClass is string) --> 'true'

However, this aliasing behavior is not extended to list-containment evaluation:

set theString to "string"

set theClass to (class of theString) --> 'text'

set theResult to (theClass is in {string, Unicode text}) --> 'false'

In my code that needs to run on both AppleScript 2.0 and AppleScript 1.9.x, I had to track down all of my string parameter validations and add 'text' to the list of valid data types:

set theString to "string"

set theClass to (class of theString) --> 'text'

set theResult to (theClass is in {string, text, Unicode text}) --> 'true'

Without simple-case type aliasing, I never would have expected the list-containment case to work. With this aliasing, it took me a bit longer to track down the source of the problems.