AppleScriptKit brings in troublesome objectSpecifier implementations

Number:rdar://7812696 Date Originated:3/31/2010
Status:Open Resolved:
Product:Mac OS X Product Version:10.6.3
Classification:Serious Bug Reproducible:Always
30-Mar-2010 08:45 PM Daniel Jalkut:
If a Cocoa application links to some framework, e.g. Automator, that in turn brings in AppleScriptKit.framework, it can have nasty effects on the scriptability of an application.

In particular, AppleScriptKit defines its own category methods for "objectSpecifier" on a number of standard classes such as NSWindow.  Their implementation of objectSpecifier does not work correctly in some instances, e.g. when the implementation class is a subclass, e.g. of NSWindow. Something about the way that it sneaks _ask to the end of the key for the to-many specifier doesn't work right. I end up getting object specifiers to my windows that have 0x0000000 for the 'want' entry.

It seems that AppleScriptKit was designed in such a way that it should never be linked to an application that is also relying on the standard Cocoa Scripting category implementations of "objectSpecifier" to behave as expected.

Whatever ASK is trying to achieve with its tricky objectSpecifier implementations, it doesn't seem right to have two frameworks, from Apple, each implementing objectSpecifier on standard AppKit classes, in differing ways. As Apple itself documents, when two category methods of the same name are implemented on a class, the selection of which will be run is undefined.

Possible solutions:

1. Apple could eliminate the use of these category methods in ASK, so that it is safe to link with arbitrary Cocoa host applications, without interfering with standard objectSpecifiers.

2. Apple could take pains to ensure that AppleScriptKit is never implicitly linked to a Cocoa application, e.g. by way of a framework such as Automator.framework. I suspect this bug affects relatively few apps because it's very uncommon to link from a standalone Cocoa app to ASK directly, and also rare to link to Automator.

3. The least desirable, but still acceptable solution, would be to take pains in ASK's objectSpecifier implementations to make sure that whatever specifiers it creates are compatible with standard scripting runtime in the rest of a Cocoa app. I.e. that they shouldn't have the weird "_ask" suffixes, or they should do some magic to make sure that the relationships with "_ask" suffixes are always evaluated as expected.

In summary: the ASK team needs to evaluate what it means for their framework to be loaded into a Cocoa application where objectSpecifier is already implemented by Cocoa Scripting on many standard objects.


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!