home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / hypercar / 4216 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.2 KB  |  45 lines
  1. Newsgroups: comp.sys.mac.hypercard
  2. Path: sparky!uunet!pageworks.com!world!eff!news.byu.edu!gatech!usenet.ins.cwru.edu!agate!apple!mumbo.apple.com!gallant.apple.com!wolverine.apple.com!user
  3. From: jpugh@apple.com (Jon Pugh)
  4. Subject: Re: Word 5.1 & AppleEvents
  5. Sender: news@gallant.apple.com
  6. Message-ID: <jpugh-171192132944@wolverine.apple.com>
  7. Date: Tue, 17 Nov 1992 21:32:23 GMT
  8. References: <1992Nov11.232622.30978@fourd.com> <7875@lib.tmc.edu> <shebs-171192100253@delos.apple.com>
  9. Organization: Apple Computer, Inc.
  10. Followup-To: comp.sys.mac.hypercard
  11. Lines: 32
  12.  
  13. In article <shebs-171192100253@delos.apple.com>, shebs@apple.com (Stan
  14. Shebs) wrote:
  15. > 
  16. > AppleEvents are like the bare X protocol.  You can write efficient code
  17. > to drive a display on the other side of a network, but it would be very
  18. > difficult.  To use the X protocol, you have Lisp and C libraries to do
  19. > the most useful things in a function call style, and then you get a
  20. > toolkit to encapsulate groups of calls into interface objects, and then
  21. > you can use a scripting language like Tcl/Tk to build useful things.
  22. > 
  23. > Personally, I think the basic API and object model is fine, but it's
  24. > very low-level and should be much less visible to normal application
  25. > developers.  AppleScript will help a lot with understanding the
  26. > high-level view of things - it can show you an English description of
  27. > an event, for instance.  We could use more toolkit-type AE support,
  28. > but I don't know what that should look like.
  29. > 
  30. > If it's any consolation, nobody else has this figured all this out
  31. > either.  Competitors are systems like OLE and ORB, but they're also
  32. > hard to use and not well-accepted yet.  Even the research world
  33. > hasn't agreed on a scheme to link objects in multiple programs.
  34.  
  35. I agree with a lot of this, but in addition I would like to point out that
  36. a lot of the design decisions were made for compatibility reasons. 
  37. AppleScript would like to be a full OOP language, but it has to be
  38. implemented in non-OOP programs. That makes it very tough to hide the
  39. implementation details.  Getting AppleScript/Object Model support into
  40. MacApp or Bedrock is more than just a good idea, it's an absolute MUST as
  41. far as I am concerned.  Of course, I'm not in charge of anything so no one
  42. really listens to me.  ;)
  43.  
  44. Jon
  45.