First off, the ASOC release notes seemed to suggest that nothing special was necessary to declare a ‘retain’ property in ASOC classes. However, if I set a property on an ASOC object from Objective-C to a value with no retained references, the next access after the enclosing autorelease pool expires results in an error. Retaining the value an extra time from Obj-C prevents that but leaks memory. Attempts to override the set method in AppleScript results in complaints about the handler being multiply defined. I don’t want to be forced into requiring GC just because of this. Is there any way to get proper retain properties in ASOC-based classes? (FWIW: what I’m doing is using ASOC as a very small part of an app mostly-written in Objective-C, because Scripting Bridge can’t seem to do one particular thing I want to do that’s easy in AppleScript code.)
Secondly, is there any way to have a method return a non-object value (e.g. an int or a double), or to have a property act as bring non-object-valued? I’d like to be able to write ASOC classes to conform to protocols that define such methods/properties, but if you introspect on any method declared on an ASOC class, it says it returns ‘id’ or something similar. I could implement primitive properties via the KVC methods if I could declare methods with the right return values/parameters.
For that matter, is there any way to declare that an ASOC class supports one or more formal protocol(s) explicitly?
That sounds strange – that’s the problem with trying to override a getter method, but setters should be fine. Can you post a sample of the code?
You can declare the methods in an ObjC superclass, or in a protocol (it just needs to be implemented by any ObjC class) – methods can only ever have one signature, so the AS class will no longer default to id. But I don’t know how the bridge will handle it – integers may still be made into NSNumbers and then cast to ints. Try it and tell us
Do it in an ObjC superclass. But if all you want to do is change method sigs, just implementing it in any class is all you need. Gets rid of all those warnings
I’ll need to experiment a bit, but at the very least: if you have a double-valued property, setting it (to anything) from Objective-C will result in it becoming a “missing value” on the AppleScript side; I haven’t tried accessing it directly from Obj-C. Also, if you call methodSignatureForSelector on an ASOC object with the property, it indicates that the set method takes an object and the get method returns one, even if a protocol exists that causes the Obj-C compiler to treat the property accessor methods as taking/returning double.
Try objc-appscript (see my sig, natch). Appscript provides a significantly more robust and capable API than SB - it’s been around since 2003 and (unlike SB) has been very heavily field tested by a lot of very demanding AppleScript users (e.g. I use it professionally to build heavy-duty Illustrator workflows, and Matt Neuburg and other folks swear by it). Its application compatibility is within a hair’s breadth of AppleScript’s, and there are various compatibility options and hooks for the very rare occasion when it isn’t 100% quirk-for-quirk compatible. The ObjC version is a little less polished than the others, but is still very usable for production purposes (you might get spurious compiler warnings about overlapping method signatures when building glues; this won’t affect functionality).
BTW, someone correct me if I’m wrong, but I’m fairly confident GC is required in ASOC-based apps. (It’s certainly marked as required in the Xcode template.)
According to Chris Nebel, it’s not required. I suspect the standard template marks it so because not using it would only make sense in very limited circumstances.
Well, I got it working without GC by having a property __foo, and then writing my own foo and setFoo handlers the same way one would write retain properties in Objective-C without @synthesize, using the __foo property as the store.
I’m not certain at this point that ASOC doesn’t leak memory in some other way with GC disabled, but we’ll see. For now though, it does seem to work.
As for objc-appscript – it looks very shiny. I’ll definitely use it in the future, but between ASOC and Scripting Bridge I’ve got things working now for my particular odd use case, so I’m not going to shake things up.
