Re: is "tell" dead?
Re: is "tell" dead?
- Subject: Re: is "tell" dead?
- From: Shane Stanley <email@hidden>
- Date: Sat, 26 Oct 2013 14:32:19 +1100
On 26 Oct 2013, at 12:08 PM, Paul Berkowitz <email@hidden> wrote:
>> But it's more time to start thinking of a future when scripting additions
>> disappear, replaced by script libraries.
>
>
> Why do you think that would of necessity be an improvement?
Scripting additions and ASObjC-based libraries both perform essentially the same function: they provide a bridge between AppleScript and lower-level Objective-C and C stuff.
Scripting additions cause terminology clashes, and they're an all-or-nothing thing: you can't just target one scripting addition. They inject code into applications. Hidden coercions have been a blessing and a bane forever. They are also much harder to write -- you can write ASObjC-based libraries in a script editor, and if you need more, it's (relatively) very simple to write and add your own Objective-C frameworks. And additions tend to be very much command-oriented, whereas libraries offer the opportunity for a more object-oriented approach, and things like a call-back ability with asynchronous commands.
Honestly, I can't see anyone setting out to write a scripting addition today, unless they want to support pre-Mavericks systems. In fact, when did anyone last see a new scripting addition appear?
> In either case, it's useful to have Standard Additions, which is already
> installed on every Mac (unless all its commands could be added to regular
> AppleScript - one wonders why that has never happened)
I don't know why they haven't been added to AS itself -- I wish they would, or even just be treated differently. During testing I tried not putting "use scripting additions" in my scripts unless needed, and I came to the conclusion that I might as well include it as a matter of course. There's stuff you don't think of as belonging to a scripting addition -- like "POSIX path of". So to me, that remains a fairly serious issue.
(And one of the reasons I wanted them off was to avoid terminology clashes. One of the side-effects of the new interleaved terminology is that breaking doThis_andThat_ into doThis: andThat: is that you are increasing the likelihood of clashes.)
> So why is one better than the other? (From either Apple's or your point of
> view, whichever you meant.)
Maybe someone from Apple will chime in with their view. But they have been pretty clear for some time that scripting additions are out of favor:
"Developers can extend AppleScript by creating bundles that provide command handlers and coercion handlers. The bundles can be applications or scripting additions. However, in many cases the best solution for extending AppleScript is to provide features through a faceless background application—that is, a sort of invisible server application."
That was before libraries. The whole design of ASObjC-based libraries looks to me like it's being positioned as the new logical choice -- it certainly offers advantages over FBAs like my own ASObjC Runner.
From my point of view, there's another important issue: there's a lot can be done in libraries based on the standard Cocoa frameworks, which means scripters themselves can write the code, or at the very least tinker with it themselves. It removes another level of dependence on third parties.
Now if only the people writing the apps would play ball...
--
Shane Stanley <email@hidden>
<www.macosxautomation.com/applescript/apps/>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden