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]
