On Jan 26, 2010, at 11:37 PM, has wrote:
> It may be the answer lies somewhere in-between: an explicit network messaging
> API with the ability to perform [read-only?] queries, but which mostly uses
> safe pointer and one-message-one-object semantics for simplicity, speed and
> safety.
I agree. Regarding objects, one of the main design goals of AppleEvents was to
enable AppleScript (AE may have shipped first, but it was invented to serve as
the substrate for AS.) Since AppleScript was envisioned as a user scripting
language, that meant enabling and encouraging an object model that reflected
the user interface of the application, not its implementation. (For instance,
the AE text object model consists of things like "paragraphs" and "words"
rather than NSAttributedStrings or DOMElements.)
So the disconnect between native objects and AE objects is deliberate. I think
a middle ground might involve having facade objects in the target app that are
bridged in a DO-like way (only less fragile) to the controlling app. These
objects would reflect the higher-level scripting API, but would know how to
translate scripting-level messages into the necessary calls to the
implementation objects. This would avoid the overhead of having to repeatedly
evaluate abstract queries ("first object of second paragraph...") on every
event.
(Actually this may already be similar to how AE resolution is done in Cocoa; I
have never worked with scriptability in Cocoa so I don't know that API.)
—Jens_______________________________________________
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 arch...@mail-archive.com
