[Camelot]

On Apple's Scripting Mail page, Apple are trying to show off how scriptable Mail (the application) is under 10.1

However, I think they could have used better examples since Mail has some pretty arcane implementations in its dictionary.

For example:

<font face = "courier">set this_message to make new compose message at beginning of every compose message
</font>

What the hell does that mean to the uninitiated?

An, even worse, what does this line try to do?

<font face = "courier">set the content of this_message to the content of this_message</font>

Now, I'm a pretty savvy AppleScripter (even if I do say so myself), but I can't work out what possible purpose this line of AS is supposed to do (other than waste time).

This isn't the way to show people the power of AppleScript. In my opinion, THE code for ANY mail application to create and send a new message should be:

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
tell application <font color = red>"Mail"</font>
set the_Msg to new message with properties (to address: <font color = red>"someone@somewhere.com"</font>, subject: <font color = red>"Test message"</font>, body: <font color = red>"Here's the body of the message"</font>)
send the_Msg
end tell
</font>[/code]

TWO lines of code is all it should take, and it should be written in such as way that any third grader could understand it. Can anyone tell me why it shouldn't be this easy? Can anyone who worked on Mail tell me why they didn't implement it this way?
Wouldn't the above code REALLY show the power of AppleScript? Anyone could look at that and think, "Wow, I could do that!" Not so with Apple's example.

The biggest problem with AppleScript is that the programmers don't put enough thought into the dictionary to make it usable by the average user. Unfortunately, as this page shows, that goes for Apple programmers, too.

Come on, Sal. Don't you have any input in this?

Get with it, Apple.

[Rickster]

No kidding. A lot of these scriptable Cocoa apps seem to have crazy AppleScript syntax requirements.

The problem looks to be Apple's implementation of the Standard Suite for Cocoa apps. It's a great idea -- the Standard Suite is generic commands like move, duplicate, delete that apply to any object; Apple implements them so that all you have to worry about is the custom properties and behaviors of your own objects.

I haven't worked much at all with Cocoa scriptability from either end, but I have a few theories as to the source of this problem:
- Apple's implementation of the Standard Suite is too generic, in that it doesn't provide as good a user experience for scripters as specific implementations in Carbon/Classic apps when it comes to complex custom objects.
- Apple's implementation locks you into a certain method of operation, where the Standard Suite becomes the only way to work with custom objects, even in cases where slightly altered standard commands or custom commands would be more appropriate.
- Apple's implementation of the Standard Suite makes it too easy for developers to ship with a half-passable degree of AppleScript support, when they should be writing custom commands to allow more sensible manipulation of their custom objects.

[bewebste]

Yeah, there are several issues that this script brings up. That "set the content of this_message to the content of this_message" line is just plain weird. It looks like a workaround for a bug in the implementation of the text suite.

The make command could be a little more understandable if they had just used the syntax "at beginning of compose messages" instead. I've always disliked that the make command's "at" parameter is required. Making it optional and allowing a default location for the new object would make it much more usable and understandable. This isn't just limited to Cocoa, either. I don't know how many times I've read questions asking why you can't use the make command with the Finder to make a new, empty file. You should be able to do this!

I wouldn't say that Apple's implementation of the standard suite in Cocoa "locks" you in to anything, although it certainly needs to be documented better. For instance, the release notes state that the implementation of the move command is very fragile and that you're very likely to have to override the default implementation. The problem is that this is buried in the release notes from several releases ago, and should be stated up front in the main docs. It is very possible to override these behaviors, but Apple needs to tell the developers in no uncertain terms a) that they are encouraged to do so to provide a better scripting experience, and b) how to do so. Leading by example in their own apps would be a good thing, too.