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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
