Next post Previous post

withTitle

June 7, 2014 at 10:26 PM by Dr. Drang

The day after the WWDC keynote, after I’d skimmed the Swift documentation, I learned from this post by Clark Goble and this tweet by Allen MacKenzie that Yosemite was going to have a new scripting language. Or maybe an old scripting language resurrected. Either way, JavaScript is going to take a spot alongside AppleScript as a way to script applications via Apple Events.1

This isn’t entirely new. Apple’s always said that OSA, the open scripting architecture behind AppleScript, could be applied to any language. Late Night Software, most famous for Script Debugger, had an OSA-capable JavaScript several years ago. And Clark says Apple had its own OSA JavaScript in the pre-OS X days. I don’t recall that, even though I was an AppleScript user back then—maybe it came out during my years in the Linux wilderness.

In any event,2 I read the JavaScript for Automation Release Notes. The OSA stuff is implemented pretty much as you’d expect, with dot notation to dig down through the object/attribute/method hierarchy. I’m not a big fan of JavaScript, but it’s certainly a more conventional language than AppleScript. I’ve forced myself to become conversant in AppleScript because it’s been the only game in town, but that doesn’t mean I like it.

Still, the devil will be in the details. The biggest problem with AppleScript has always been with the applications that implement it. Each app gets to decide which features get exposed and what they’re called. This has led to similar concepts getting different names in the dictionaries of different apps. I doubt that JavaScript will solve that problem.

In fact, I ran across a disturbing bit of syntax in the release notes. It’s the sample code in the Scripting Additions section:34

javascript:
app = Application.currentApplication()
app.includeStandardAdditions = true
app.say('Hello world')
app.displayDialog('Please enter your email address', {
    withTitle: 'Email',
    defaultAnswer: 'your_email@site.com'})

What bothers me is the two-item object that serves as the second argument to the displayDialog method. A key named defaultAnswer makes sense, but who in their right mind would name a key withTitle instead of just title?

If you know the AppleScript equivalent of this code, you can make a pretty good guess.

applescript:
display dialog ¬
  "Please enter your email address" with title "Email" default answer "your_email@site.com"

I suspect someone decided to create key names automatically by jamming together whatever AppleScript words preceded each value and intercapping them. No thought given to whether the resulting name would be natural for a JavaScript programmer or not. PyObjC did similar things in transforming Objective C calls into Python, which is one of the reasons I never got into PyObjC.

I have some hope that it’s early enough for Apple to fix problems like this. There’s an old saying: “Fortran programmers can write Fortran in any language.” Unless the language specs change, we’re going to be asked to write AppleScript in JavaScript.

  1. Earlier this evening, Federico Viticci linked to a WWDC session video entitled “JavaScript for Automation.” I haven’t watched it yet. If it contradicts anything I say here, I’ll come back and update the post. ↩

  2. I slay me. ↩

  3. I’d give you a link to the section, but Apple doesn’t seem to understand how to make internal document links. I’m sure they’ll get the hang of this HTML thing eventually. ↩

  4. I’ve reformatted the code here because Apple also doesn’t seem to understand the difference between pre and ul tags. Give them time. They’ve only been in the HTML spec since the 90s. ↩

Next post Previous post