[PYTHONMAC-SIG] AppleScript and the NeXTMac OS

[Bill Bedford]

This was posted on the Applescript List, and a few others, I thought it
might be of interest to people here.

~X-URL: http://www.infoworkshop.com/~jonpugh/
~Date:         Sat, 11 Jan 1997 00:02:20 -0800
~Reply-To:     Macintosh Scripting Systems <MACSCRPT@LISTSERV.DARTMOUTH.EDU>
~Sender:       Macintosh Scripting Systems <MACSCRPT@LISTSERV.DARTMOUTH.EDU>
~From:         Jon Pugh <jonpugh@FROSTBITEFALLS.COM>
~Subject:      Re: AppleScript and the NeXTMac OS
~
~Well, I guess that's my cue...
~
~First off, nothing I say here is official Apple policy.  This is
~essentially a summary/continuation of a discussion that started on the
~OpenDoc-Interest mailing list in the beginning of December.  I've
~crossposted this to MacScripting, AppleScript Users and OpenDoc Interest
~because I think everyone wants to know what's going on.  I know I do.  ;)
~
~I didn't hear about the NeXT deal until you folks did, so I'm still
~absorbing it and providing my feedback when asked, but this discussion
~started before that happened, and it hasn't changed much, so I think that
~validates a lot of the reasons for doing it.
~
~I've been trying to decide what to do about OpenDoc and OSA.  We've all
~been hampered by a number of aspects of AppleScript.  Notably it's lack of
~improvement.  Given OpenDoc's cross platform aspects, and AppleScript's
~lack of those cross platform aspects, AppleScript is proving to be of
~limited use.  Thus, we must consider other options.
~
~The J word is what comes in here.  Java could suffice as a scripting
~language if you had an OSA implementation of it.  It's too geeky for a lot
~of people, so an AppleScript/HyperTalk kind of thing would still be nice,
~but considering that programmers like working in Java, it should be an easy
~sell.
~
~An OSA Java would let us compile a bunch of classes up into a standalone
~script.  We could use our own interface with run, open, idle and quit, as
~well as the applet interface.  That would be a fine start.  Using Frontier,
~you ought to be able to nest classes in the odb.  Should be cool.
~
~Then, we could bridge AppleEvent subroutine events, like the ones
~AppleScript and Hypercard use, into Java methods called by name.  To send
~messages back, we'd need to have a package which allowed you to build
~AppleEvents, much like Frontier does.
~
~We could even implement a new security module since we'd like to allow more
~access than an applet but still disallow some kinds of operations.  I think
~a control panel the user could set would be nice.  That would allow one
~person's OSA Java to check for virus type actions while letting us geek
~boys do those kinds of potentially dangerous operations without complaint.
~
~So, if we had a Java OSA component, what would that buy us in OpenDoc?
~That's my responsibility after all.
~
~Well, we could build a system which attaches Java code to OpenDoc objects
~pretty easily.  Part editors could use it to attach code to their objects
~too.  You could use AppleScript, Java or any OSA language.  This is the
~value of the OSA.  We could do that in our C++ implementation if we like,
~or in some new implementation draft pick to be named later.
~
~Now, we would need a few more things for this to be truly cool though.  In
~addition to the package which allows us to build AppleEvents and object
~specifiers, we'd need to be able to send and receive AppleEvents.  Since
~this is Java, we have IP easily.  We also have the MacOS, so we have
~AppleTalk.  Assuming we have OpenTransport or something equivalent on the
~newOS, we could do a portable AppleTalk implementation, but that would
~involve rewriting the AppleEvent manager in Java.  That would enable AEIP
~and it would do wonderful things for the interface and performance.
~Considering that the AE manager is interpreted 68K right now, a Java AEM
~would run as fast or faster.  We'd get IP easily and we'd get garbage
~collection.  This would remove all the copying that the AEM does now, which
~should improve performance of AE code immensely.
~
~Then we need to parse incoming AEs and map them to Java methods.  We also
~need to be able to parse object specifiers so that we can talk with
~AppleScript and use them for remote object references.  I still like the
~way whose clauses map to lists which are resolved remotely.  I think it
~would be worthwhile keeping those in our brave new world.
~
~We can also use standard Java RPC methods, including their 1.1 scripting
~features, although these won't talk to other OSA languages.  While I'm at
~it, I'd add a new call to the OSA component interface, which is a
~CallByName kind of method that would correspond to the subroutine
~AppleEvent.  Right now you have to build an AE and use ExecuteEvent or such
~to send the event to the script.  I think it would be better to hide that
~common implementation in a standard OSA call which takes a method name and
~an array of parameters.
~
~So, we basically rewrite the AEM and the OSL in Java as well as doing the
~OSA Java.  Piece of cake.  ;)
~
~Of course, we'd get a cross platform implementation, most of it at least,
~depending on the AppleTalk capabilities we can use or reimplement.  We
~don't really get a scripting language, but we can use either an existing or
~new OSA AppleScript.  You'd have to program in Java using this new package
~interface, but it should be pretty nice to deal with.
~
~We could also add an object resolution framework much like ODF uses in C++.
~In Java and without the OSL, it'll be a lot cleaner too.  My questions now
~revolve around building a decent OOP framework for resolving whose clauses.
~It would be simple enough to build a framework which iterated through all
~the objects and compared them to a literal, but the trick comes in allowing
~someone to override everything properly and add other more efficient
~searches of the objects when appropriate.  Ideas are welcome here, as are
~they everywhere else.  It sounds like it shouldn't be too hard to do
~simply, but I can imagine people making it difficult with legacy code and
~database stuff.  ;)
~
~So, that's what I've been thinking about.  I'd like to see a new and
~improved AppleScript, but I'm not holding my breath.  Of course, I'm not
~holding my breath about this stuff yet either.  It sounds like a sensible
~plan given the whole Java emphasis that everyone is into these days, but
~there's still plenty of work to do and few people to do it.
~
~Feel free to comment and question things.  Remember to color outside the
~lines.  This is all just brainstorming at this stage.
~
~Jon

-----------------------------------------------------------------------
 Bill Bedford                                  Designer of Photo-Etches
 billb@mousa.demon.co.uk


               owner Brit_Rail-L  ---  british railways historical list

 -----------------------------------------------------------------------


=================
PYTHONMAC-SIG  - SIG on Python for the Apple Macintosh

send messages to: pythonmac-sig@python.org
administrivia to: pythonmac-sig-request@python.org
=================