Re: Problems with ScriptingBridge and iTunes
Re: Problems with ScriptingBridge and iTunes
- Subject: Re: Problems with ScriptingBridge and iTunes
- From: has <email@hidden>
- Date: Mon, 3 Mar 2008 21:45:14 +0000
On 3 Mar 2008, at 15:27, Steven Degutis wrote:
Thank you for the update on that sample code. I was hoping it would
continue to be ignored because I was publicly berated in the #macdev
channel for posting it, but oh well.
Don't feel too bad: if you're coming from a Cocoa background,
application scripting is a very different beast to what you're used
to, and Scripting Bridge's deliberately dishonest design is pretty
much guaranteed to give you a completely incorrect understanding of
how it works if you pay any attention to it.
Like I say, the basic principles are actually pretty simple, and most
of the confusion here is down to AppleScript's use of OO-like
syntactic sugar. While it certainly makes Apple events easier to use,
it also encourages unsuspecting newcomers to assume that because it
looks OO-ish, it *is* OO. This wouldn't be such a big problem if the
AppleScript documentation clearly indicated that the OO-like syntax is
purely for ease of use, before explaining the actual RPC+query-
oriented mechanics behind it. Unfortunately, the AppleScript
documentation heavily [over-]simplifies the technical details,
presumably in an attempt to make them easier to understand.
This sort of creative fictionalising might be an acceptable compromise
to make for the non-technical audience that AppleScript is primarily
aimed at, but it's a real pain for professional programmers trying to
make sense of AppleScript technology. In the absence of better
information, the typical Mac programmer will look at the existing
AppleScript syntax and documentation and from that conclude that it
since it looks like OO, it must behave like it as well. Again, most of
the actual behaviour is close enough to what's anticipated that most
folks manage to get by for most of the time, even with a flawed
understanding of what's going on. However, it hardly inspires any sort
of confidence in the technology when you're less than certain what
exactly is going on, and troubleshooting your code whenever something
does go wrong is going to be difficult at best. Non-programmers may
tolerate this simply because they don't realise when they're being
messed around, but professional developers generally have better
things to do with their time and don't take kindly to such treatment.
Thanks to Wolf's post up there,
I'm not going to continue to learn SB any longer, and I just hope
Apple fixes it up.
While SB isn't so utterly defective as to be unusable, it still isn't
close to being an improvement over AppleScript. If you want to control
scriptable applications from other languages then appscript remains
the best technical choice. Again, my advice would be to read the
appscript documentation, William Cook's AppleScript papers, Matt
Neuburg's AppleScript book, and spend a bit of time playing around
with appscript (the Python and Ruby versions are particularly good for
exploring application scripting since they can be used interactively
and provide very nice built-in help). You'll still have to deal with
the many quirks, bugs and other shortcomings of individual scriptable
applications, but at least you don't have to put up with a third-rate
language/bridge on top of that.
HTH
has
--
http://appscript.sourceforge.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden