Swift Scripting (Part 2)

In part one of this series, we covered the basics of the Scripting Bridge and how one might leverage this technology with Swift. We left off with some potential problem areas. Specifically, we saw that the default approach for leveraging the sdp-generated Objective-C interface could lead to ambiguity on the Swift side of things.

Let’s now take a closer look at an example of such an ambiguity. The excerpt below is from the sdp-generated header file for the Acorn image editor. Incidentally, Acorn is an excellent product and if you’re searching for an image editor you should check it out!

@interface AcornApplication : SBApplication
// The name of the application.
@property (copy, readonly) NSString *name;

// The version number of the application.
@property (copy, readonly) NSString *version;  

 // Have Acorn taunt you.
- (NSString *) taunt; 
@end

Here’s some sample code that demonstrates how we might access the version property of the application.

import Foundation
import ScriptingBridge

let acorn: AnyObject = SBApplication(bundleIdentifier: "com.flyingmeat.Acorn4")!
print(acorn.version)

The above code will not compile. The problem is that the acorn variable must be declared to be of type AnyObject. Since there are multiple, conflicting definitions of version declared in different classes, the compiler cannot resolve the version property uniquely. Here we can resort to using valueForKey("version") to work around this issue. In other cases, where we want to invoke a method as opposed to simply retrieving the value of a property, this ambiguity can force awkward method invocations such as

object.someMethod() as Void

The above construct would be necessary if there were multiple someMethod implementations defined with different return types, where the desired invocation returns Void. As mentioned in part one, we can avoid the ambiguity entirely by defining one or more Swift protocols that cover the Objective-C API. For the subset of the Acorn API shown above, an equivalent set of Swift protocol looks like this

import AppKit
import ScriptingBridge

@objc public protocol SBObjectProtocol: NSObjectProtocol {
    func get() -> AnyObject!
}

@objc public protocol SBApplicationProtocol: SBObjectProtocol {
    func activate()
    var delegate: SBApplicationDelegate! { get set }
}

@objc public protocol AcornApplication: SBApplicationProtocol {
    // The name of the application.
    optional var name: String { get } 

    // The version number of the application.
    optional var version: String { get } 

    // Have Acorn taunt you.
    optional func taunt() -> String 
}
extension SBApplication: AcornApplication {}

Here we’ve defined two base protocols to represent the commonly used functionality of the SBObject and SBApplication classes. The AcornApplication protocol extends the SBApplication protocol and includes the version property. Note that all properties and methods in the AcornApplication protocol are declared as optional. Also note that the extension on SBApplication indicating that it conforms the AcornApplication has an empty implementation.

With these protocols defined, we can alter the code to use explicit typing and access the version property directly.

import Foundation
import ScriptingBridge

@objc public protocol SBObjectProtocol: NSObjectProtocol {...}
@objc public protocol SBApplicationProtocol: SBObjectProtocol {...}
@objc public protocol AcornApplication: SBApplicationProtocol {...}
extension SBApplication: AcornApplication {}

let acorn = SBApplication(bundleIdentifier: "com.flyingmeat.Acorn4") as! AcornApplication
println(acorn.version!)

Here we have explicitly-typed the acorn variable and we have direct, unambiguous access to the version property. A downside of this approach is that we need to deal with the optional nature of the properties and methods in the protocol. Here we’ve done that by using the ! when dereferencing the version property.

In part three of this series, we’ll look at how the generation of the necessary Swift protocols can be automated and how the resulting code can be packaged up as a Framework to support reuse in a variety of scripts.

4 thoughts on “Swift Scripting (Part 2)

  1. @Joe: Yes, thank you for pointing out that alternative. You could also use

    println(acorn.version as String!)

    to unwrap the optional. I’ve updated this post to soften the wording with regard to method resolution.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s