NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/mac/hypercar/4231

Text File | 1992-11-18 | 4.5 KB | 94 lines

Newsgroups: comp.sys.mac.hypercard
Path: sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!apple!mumbo.apple.com!gallant.apple.com!delos.apple.com!user
From: [e-mail] (Stan Shebs)
Subject: Re: Word 5.1 & AppleEvents (actually AppleScript)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1992 18:22:32 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Apple Computer Inc.
Followup-To: comp.sys.mac.hypercard, comp.sys.mac.programmer
Lines: 81

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:
>
> In article <[e-mail]>, [e-mail] (Jon Pugh) writes:
> > [...] I would like to point out that
> > a lot of the design decisions were made for compatibility reasons.
> > AppleScript would like to be a full OOP language, but it has to be
> > implemented in non-OOP programs.
>
> Why? AppleScript is a language in its own right, right? So how would you
> embed AppleScript code inside programs written in other languages? It seems
> to me the natural way would be to store AppleScript sequences (possibly in some
> "tokenized" or other such "pseudocompiled" form) in resources or suchlike.
> So why should that have any interaction with the language that the rest of the
> program is written in?
>
> > That makes it very tough to hide the implementation details.

The OSA interface is the basis for talking to a script engine.  For
instance, it allows you to do something like this in your source code:

         sprintf(buf, "((%d - 32) * 5) / 9 ", fahr);
         rslt = OSAExecute(buf);

and get a result, in case implementing your own converter is hard to do
:-).
Perhaps a better example would be

         sprintf(buf, "next move of white given %s",
chess_board_in_ascii());
         rslt = OSAExecute(buf);

where the "next move" handler connects to a chess-playing program.  Note
that for both of these examples, the script can do its work without
knowing anything more than what's passed to it.  Unfortunately, this
only handles a small percentage of what one might want to do with scripts.

As a more realistic example, suppose you've acquired a cool tiling
script that, given a collection of windows, moves and sizes them to be
non-overlapping, and that your app has a "Tile Windows" menu item to attach
the script to.  Then you could write something like

                                ...
                                case miTileWindows:
          OSAExecute("tile windows of application \"xxx\");
          break;
        ...

where xxx is filled in by your app.  How does the script collect the sizes
and positions of your windows and then tell the application how to change
them?  Plan A would be to implement a special AppleEvent that passes back a
list of window ids, resizeabilities, and dimensions, something like

        {{1, true, 30, 30, 400, 500}, {2, false, 200, 100, 300, 452}}

and then have the script dissect the list in classic Lisp fashion.  This
is pretty inefficient and inflexible though, especially for an application
more complicated than TeachText.  An application that supports the object
model allows you to ask for just the "position" property of a "window"
object and get back, say, {400, 500}, and you only need to do that for the
windows whose "resizeable" property was "true".  So with Plan B, your
application only defines event handlers for accesses to windows and their
properties, while the script engine handles the composing of events that
acquire or modify those properties.  This is actually simpler and *more*
efficient than trying to define huge numbers of event types! (plus Jon
is happier because he has fewer types of events he has to register :-) )

One significant advantage of the AE object model is that you can
implement the objects of your application in *any* way you so desire.
You don't have to make anything elaborate, in fact using the refCon
field of a window for an object id works perfectly well.  As long as
your application makes it *appear* as though it has window objects,
the rest of the AE world is happy.

For an idea of what a full object model can buy you, look at the latest
Filemaker Pro(tm, no doubt), which not only has lots of classes and
properties, but it documents them very nicely with a Filemaker database!

Stan Shebs
Apple ATG System Software
[e-mail]