home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!comp.vuw.ac.nz!waikato.ac.nz!ldo
- From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
- Newsgroups: comp.sys.mac.hypercard
- Subject: Re: Word 5.1 & AppleEvents
- Message-ID: <1992Nov18.171125.12285@waikato.ac.nz>
- Date: 18 Nov 92 17:11:25 +1300
- References: <1992Nov11.232622.30978@fourd.com> <7875@lib.tmc.edu> <shebs-171192100253@delos.apple.com> <jpugh-171192132944@wolverine.apple.com>
- Followup-To: comp.sys.mac.hypercard
- Organization: University of Waikato, Hamilton, New Zealand
- Lines: 26
-
- In article <jpugh-171192132944@wolverine.apple.com>, jpugh@apple.com (Jon Pugh) writes:
- > In article <shebs-171192100253@delos.apple.com>, shebs@apple.com (Stan
- > Shebs) wrote:
- >>
- [comments about the difficulty of supporting AppleEvents omitted]
- >
- > I agree with a lot of this, but in addition 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.
-
- You don't have to be OOPish (OOPful?) to support data abstraction. Try Modula-2.
-
- Lawrence D'Oliveiro fone: +64-7-856-2889
- Computer Services Dept fax: +64-7-838-4066
- University of Waikato electric mail: ldo@waikato.ac.nz
- Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
-