[PYTHONMAC-SIG] AppleScript and the NeXTMac OS
Bill Bedford
billpy@mail.demon.net
Sat, 11 Jan 1997 12:20:27 +0000
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
=================