Re: Problems with ScriptingBridge and iTunes

FROM : has
DATE : Mon Mar 03 16:21:33 2008

Jens Alfke wrote:

> Moreover, since Obj-C is a dynamic language, it's more important what
> the class of the object is at runtime, than what type the pointers are
> defined as at compile time. You can change the type declarations, but
> it won't affect what actual objects you get back at runtime.



This is particularly true when dealing with scriptable applications, 
given that the type information provided by application dictionaries - 
which is what sdp uses to generate Scripting Bridge headers - is not 
always accurate.

Most of the information provided by application dictionaries is only 
there for documentation purposes and is completely ignored by 
AppleScript. Given that application developers have spent the last 
decade designing and testing their applications to work with 
AppleScript, it's not unusual for errors in the documentation-only 
portions of the application dictionary to slip through. For example, 
iTunes' 'add' command claims to return a 'track' reference, but it 
actually returns a list of track references if more than one file is 
supplied.

Another problem is that the dictionary format - particularly the older 
aete format which is still used by most applications - is a bit 
limited in its expressiveness, so even a dilligent developer may be 
unable to describe every last detail of a particular command's 
parameter and return values. For example, Address Book's dictionary 
states that a 'person' object's 'last name' property contains a 
string, and it usually does; however, it can also contain a 'missing 
value' constant if a person's last name isn't known.

This is why objc-appscript simply declares all property, parameter and 
return types as 'id', on the basis that the user will know more about 
the types of values that a particular application will accept and 
return than it does, and perform any necessary type checks themselves. 
It also provides several convenience methods (-returnType:, -
returnList, -returnListOfType:, -returnDescriptor) for ensuring a 
return value is converted to a specific type (or an error raised), 
which is handy for dealing with carelessly inconsistent commands such 
as 'add' (which, if it was better implemented, would _always_ return a 
list, regardless of how many files are supplied).

...

BTW, if all this sounds a bit untidy and less than ideal for users... 
well, it is. Alas, while the principles behind Apple event IPC are 
simple enough, the day-to-day practicalities of using it are a bit 
more complicated due to the great variations in design and quality 
between individual applications' scripting interfaces. Scripting 
Bridge, whether by hubris, naïveté or embarrassment, attempts to gloss 
over the flaws and imperfections of AppleScript's world and pretend 
that they don't exist. Appscript, OTOH, accepts the current situation 
on its own terms and merely aims to provides you with a good, solid 
set of tools for dealing with it. It might not look quite as pretty or 
'pure' as SB, but it shouldn't jump up and bite you on the butt when 
you aren't expecting it either.

HTH

has
--
http://appscript.sourceforge.net