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

_______________________________________________

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]

Reply via email to