On 24/05/2012, at 2:22 PM, Christopher Stone wrote:
Enticing why?
It's easier. In pre-Cocoa Scripting apps, if a command or parameter returned, say, an alias, the developer had to convert his internal file object into an Apple event descriptor of an alias to pass back to the script. Similarly, if an app accepted an alias as a parameter or for a property, the descriptor had to be converted to something useful. Not rocket science, but conversion code to be written and maintained.
In Cocoa scripting, if the dictionary is an .sdef file specifying a type of "file", the conversions happen automatically; the developer can return an NSURL (a file URL), and Cocoa Scripting will convert it into a «class furl» as its passed to your script. Given that NSURLs are what Cocoa developers work in, that's more convenient.
And going the other way it's even more convenient, both for developers and scripters. We can pass aliases, «class furls», POSIX paths (as long as they are full paths) or HFS paths[1], and Cocoa Scripting converts them all and passes them on as NSURLs.
It happened in 10.6, I think, although that may just have been when things like standard additions started taking advantage of it. Things like "choose file name" started returning «class furl», and the read and write commands started accepting raw HFS and POSIX paths.
[1] has-note: HFS paths must begin with a valid volume name, or else they'll be prepended by the name of the startup disk, with sometimes disastrous results. Same as coercing a string to a «class furl»:
"blah:blah2:blah3:blah4" as «class furl» --> file "Macintosh HD:blah:blah2:blah3:blah4" "blah:blah2::blah3:blah4" as «class furl» --> file "Macintosh HD:blah:blah3:blah4"
|