Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: on OSA (was Re: What's so great about AppleScript, anyway?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: on OSA (was Re: What's so great about AppleScript, anyway?)



Philip Aker wrote:

- complete independence from Apple events (the two technologies may be synergistic, but they should *not* be inter-dependent [3])

I didn't state it in my post to this list but I have devised a rather complete plan to have all the structural aspects of AE.framework to be available in CoreFoundation.

Oh, I agree with that idea - the same can be said of most Carbon APIs. Core Foundation is far better, not to mention more pleasant, to work with than the old-style pre-OS X APIs. CF's reference-counting memory management scheme alone makes it worth the price of admission IMO.



Sketches (at least 3 of them) have been posted to the Carbon list quite some time ago. Anyone familiar with the 'class' hierarchy from AEDesc through AppleEvent can see what a breeze that portion would be.

One of my wish-lists for objc-appscript is CF bridging for its 'AEM' APIs, as that would make application scripting easily accessible to a significantly larger market (e.g. C++, Java, scripting languages without an ObjC bridge). If you fancy having a go, please be my guest.


As for CF wrapping of the server-side APIs, for all my dislike of CocoaScripting's faults it remains, as far as I can tell, the only halfway credible game in town, so CF bridging of that API, while not ideal, would probably make the most sense. (Unless you have a spare year and fancy writing a CocoaScripting killer too.)


A little more complicated is the added CFNumber types (unsigned ints + special case for OSType),

Haven't looked at the problem, so no comment.


added polymorphic functions,

Dunno what that means here, but I'm sure it's all good.


and query API set.

Again, appscript's 'AEM' API already provides ObjC classes for constructing object specifiers; it should be straightforward to reimplement and/or bridge them in CF.



However the benefits would be extraordinary considering that the result would be a small but extensible 'class' system expressible in C -- that means deployment possibilities on all major platforms and adaptability to most object- oriented languages.

Bear in mind that Apple have a vested interest in *not* making their exclusive technologies easily reproducible on other major platforms. So if that's what you're after then better get cracking on it yourself as I can't see Apple ever touching it. :)


Cheers,

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.