Re: Problems with ScriptingBridge and iTunes

FROM : has
DATE : Mon Mar 03 22:45:14 2008

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