johnson@m.cs.uiuc.edu (09/16/90)
Peter Grandi gives an impressive list of object-oriented languages. There were several that I didn't know about. However, I would like to quarrel with his characterization of Smalltalk. C++ is by far the most popular object-oriented language for commercial use in the U.S. However, Smalltalk might very well be in second place. Eiffel or Objective-C might have second place, but not by much. I know of quite a few companies building products in Smalltalk. Also, ParcPlace Smalltalk is not expensive for universities because of their site license. The site license makes it quite reasonable to teach classes with it. On the other hand, it certainly is expensive outside universities, though not as much as it used to be. I like to use Smalltalk to teach object-oriented programming because the class library makes a great set of examples. The programming environment makes programming fun, which always helps a class. On the other hand, lots of other o-o languages come with good class libraries and a nice programming environment. Unfortunately, C++ is not one of them. Ralph Johnson -- University of Illinois at Urbana-Champaign
pcg@cs.aber.ac.uk (Piercarlo Grandi) (09/17/90)
On 16 Sep 90 04:37:00 GMT, johnson@m.cs.uiuc.edu said: johnson> However, I would like to quarrel with his characterization of johnson> Smalltalk. C++ is by far the most popular object-oriented johnson> language for commercial use in the U.S. However, Smalltalk johnson> might very well be in second place. I may be mistaken, but I have not yet seen that many *products* being sold that were implemented in Smalltalk, either -80 or /V. On the other hand I would agree that a lot of companies use Smalltalk for *internal* purposes, that range from prototyping (most often) to AI and user interfaces. johnson> Eiffel or Objective-C might have second place, but not by much. Well, I have seen papers on several *very large* systems being commercially developed and sold in Objective C and Eiffel. johnson> I know of quite a few companies building products in Smalltalk. This I cannot know -- I am far removed from the scene, unfortunately. I do know of some products in Smalltalk, now that I think of it. Several packages from Xerox, and of course the development environments from ParcPlace Systems. Also, I have heard rumours about financial packages, but people that do these are usually fairly secretive. johnson> Also, ParcPlace Smalltalk is not expensive for universities johnson> because of their site license. The site license makes it quite johnson> reasonable to teach classes with it. Well, I have just been told about their site licensing program. You pay a couple grand and you have a campus wide license for one CPU type (e.g. Sun-3 or Intel or...). Not a bad deal. johnson> I like to use Smalltalk to teach object-oriented programming because johnson> the class library makes a great set of examples. The programming johnson> environment makes programming fun, which always helps a class. On the johnson> other hand, lots of other o-o languages come with good class libraries johnson> and a nice programming environment. Yes, but admittedly nothing is quite like Smalltalk in that respect -- it's the Rolls-Royce of the OO languages. I have seen an Objective C environment that competes with it though. johnson> Unfortunately, C++ is not one of johnson> them. Uhm. Uhm. For all its defects, C++ surely has a large collection of class libraries. Its user programming environment is the standard Unix one, which is fairly tolerable. There also exist several C++ browsers, some for GNU Emacs, some stand-alone, like Brown Unviersity's one. Nothing as smooth as Smalltalk's, admittedly. Frankly, my reply was slanted towards the needs of somebody who clearly wanted to provide more job oriented training than ivory tower education, and without spending much money. I will be the first to admit that Smalltak, for understanding what OO is all about, is vastly better than C++, but for job-related experience, the latter is on another plane. If the only gauge is to be insight/education in OO *languages*, then I would lean towards using something basd on Scheme on one hand, or Simula 67 (or, and I did not mention it because implementations are not that easy to come by, BETA). If OO *environments* is the gauge, then there is little alternative to Smalltalk, but for maybe Objective-C, e.g. as in the very beautiful environment developed in a joint HP/Stanford project, which is highly competitive with the Smalltalk one. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
brucec@phoebus.phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) (09/18/90)
In article <77500057@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu writes: > > I like to use Smalltalk to teach object-oriented programming because > the class library makes a great set of examples. The programming > environment makes programming fun, which always helps a class. On the > other hand, lots of other o-o languages come with good class libraries > and a nice programming environment. Unfortunately, C++ is not one of > them. > There's an additional reason for learning the basics of OOP from Smalltalk (or rather, not from C++): the model is clean and easy to see and understand. Everything is an object; there aren't any special cases, and there isn't a lot of hairy syntax. I learned Smalltalk first, so that when I came to C++ I understood the basic concepts, and could concentrate on learning the complexities of the language. Several people I know were exposed to C++ first; their knowledge of C didn't help them understand the object paradigm, or with the additional complexity of C++. They were well out to sea for some time, and it wasn't until they actually had used the language in a fair-sized project that they understood the application of the object concepts. Before someone starts another "first languages can permanently damage your brain" flamewar, let me point out that these people did eventually understood what was going on, but it took longer and was considerably more painful than it needed to be. -- --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077
lgm@cbnewsc.att.com (lawrence.g.mayka) (09/18/90)
In article <PCG.90Sep17170851@odin.cs.aber.ac.uk>, pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > On 16 Sep 90 04:37:00 GMT, johnson@m.cs.uiuc.edu said: > johnson> Eiffel or Objective-C might have second place, but not by much. > > Well, I have seen papers on several *very large* systems being > commercially developed and sold in Objective C and Eiffel. Also, many commercial systems are written in Common Lisp with Flavors or (nowadays) CLOS. > johnson> environment makes programming fun, which always helps a class. On the > johnson> other hand, lots of other o-o languages come with good class libraries > johnson> and a nice programming environment. > > Yes, but admittedly nothing is quite like Smalltalk in that respect -- > it's the Rolls-Royce of the OO languages. I have seen an Objective C > environment that competes with it though. You might want compare these with the better CLOS development environments, such as LispWorks, or most of all with the Symbolics Genera system. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
pcg@cs.aber.ac.uk (Piercarlo Grandi) (09/21/90)
On 18 Sep 90 02:11:16 GMT, lgm@cbnewsc.att.com (lawrence.g.mayka) said: lgm> In article <PCG.90Sep17170851@odin.cs.aber.ac.uk>, lgm> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> On 16 Sep 90 04:37:00 GMT, johnson@m.cs.uiuc.edu said: johnson> Eiffel or Objective-C might have second place, but not by much. pcg> Well, I have seen papers on several *very large* systems being pcg> commercially developed and sold in Objective C and Eiffel. lgm> Also, many commercial systems are written in Common Lisp with Flavors lgm> or (nowadays) CLOS. This is interesting news (for CLOS), at least to me. The 500 pound jellyfish vs. the 500 pound gorilla :-) :-) :-). johnson> On the other hand, lots of other o-o languages come with good johnson> class libraries and a nice programming environment. pcg> Yes, but admittedly nothing is quite like Smalltalk in that respect -- pcg> it's the Rolls-Royce of the OO languages. I have seen an Objective C pcg> environment that competes with it though. lgm> You might want compare these with the better CLOS development lgm> environments, such as LispWorks, or most of all with the Symbolics lgm> Genera system. Well, Symbolics environments tend to be the Rolls Royce, floor wax, dessert topping, Swiss Army chainsaw, surgeon's toolkit, etc... of environments :-) :-) :-). And now on boldly to a completely different tune! I have received requests for information on where to get some of the good things I had mentioned. I should have also mentioned MOB, GNU smalltalk, SCIX, and many, many, many others, incidentally. Here is a (very partial) compilation, after a quick scan of my archives: (what follows is a UNIX mail(1) style mailbox, shifted right two columns) From SCHEUTJENS@RCL.WAU.NL Mon Jan 15 19:33:48 1990 From: SCHEUTJENS@RCL.WAU.NL (Jan Scheutjens) Newsgroups: bit.listserv.simula Subject: Simula filelist Date: 9 Jan 90 23:23:02 GMT Reply-To: The SIMULA Language List <SIMULA@BITNIC> X-VMS-To: IN%"Simula@hearn" XDate: Tue, 9 Jan 90 18:57:00 MET Status: RO A Simula filelist with Simula stuff is opened on Bitnet/EARN! One of the goodies on the server is the Public Domain Macintosh/MPW Simula compiler (version 4.07 of Lund Simula). Get the filelist by sending GET SIMULA FILELIST as a command or the first line of your mail to Listserv@DEARN. Please, check your archives for any Simula programs or modules that may be of general interest and send them to me for the Filelist. Also additions and corrections for the files with general information are welcome. Let us make Simula even more useful! Jan. From mikeg@stpstn.UUCP Sat Mar 31 16:35:42 1990 From: mikeg@stpstn.UUCP (Mike Goda) Newsgroups: comp.newprod Subject: The Objective-C Browser availability Keywords: Objective-C, Browser Date: 28 Mar 90 17:20:29 GMT Reply-To: mikeg@stepstone.com (Mike Goda) Followup-To: poster Organization: The Stepstone Corporation, Sandy Hook, CT 06482 Status: RO The Stepstone Corporation proudly presents The Objective-C Browser and Promotional Campaign Built with Stepstone's Graphical User Interface library (ICpak201), the Objective-C Browser aids software engineers in developing and analyzing programs written in C or Objective-C languages with the same look and feel across multiple hardware platforms. Features include: Analysis of: Inheritance Behavior trace Self/Super resolution Summary reports Cross-reference facility shown by: file referenced function referenced global variables Objective-C classes Objective-C methods instance methods Browsing C: Files Functions Global Variables Hierarchial database exploration to access information in great detail through menu selections On-line help Ability to save analysis information to an ascii file Searching capabilities Tear-off copy of the working panel The Objective-C Browser is currently available on: Sun 3 SunOS 3.n and 4.n \ Sunview Sun 386i SunOS 4.n > and Sun 4 SunOS 4.n / X11.3 The following platforms are planned for release this quarter VAX station 2000 and compatible under ULTRIX 3.0 HP 9000 Series HP-UX 6.5 + 7.0 Apollo Domain 10.1 DEC station 3100 and compatible (RISC) ULTRIX 2.0 PC-RT, PS/2, and RISC SYSTEM/6000 AIX (Current versions) Data General AViiON systems (planned for 2nd quarter) In case you are not familiar with Stepstone's product set, I am providing the following information. Objective-C Compiler Version 4.0 -------------------------------- Runs on the following: Sun 3 SunOS 3.n and 4.n Sun 386i SunOS 4.n Sun 4 SunOS 4.n VAX station 2000 and compatible under ULTRIX 3.0 DEC station 3000 and compatible (RISC) ULTRIX 2.0 HP 9000 Series HP-UX 6.5 and 7.0 Apollo Domain 9.7 and 10.1 PC-AT (or compatible) DOS 3.3 MSC 5.1 PS/2 (or compatible) OS/2 1.1 MSC 5.1 IBM PC-RT, PS/2 and RISC SYSTEM/6000 AIX (current version) Data General AViiON systems (To be released this quarter) ICpak201 Version 2.1 (Graphical User Interface Library) ------------------------------------------------------- Runs on the following: Sun 3 SunOS 3.n and 4.n Sun 386i SunOS 4.n Sun 4 SunOS 4.n VAX station 2000 and compatible under ULTRIX 3.n (To be released this month) DEC station 3100 and compatible (RISC) ULTRIX 2.n (To be released this quarter) HP 9000 Series HP-UX 6.5 (HP-UX 7.0 to be released this quarter) Apollo Domain 9.7 (Domain 10.1 to be released this quarter) IBM PC-RT AIX 2.2.1 (PS/2 and RISC SYSTEM/6000 2nd Quarter 1990) Data General AViiON systems (To be released 2nd quarter) ****************************** * NOTE TO ALL UNIVERSITIES * ****************************** The Stepstone Corporation has in progress a promotional campaign targeting Colleges and Universities. Any Educational Institution can receive any or all of Stepstone's product(s) and educational courses at a special University discount. Department, Building, or Site licenses are available. If interested in participating in this campaign, please forward this mail message to your Computer Science Professor or appropriate faculty member. Stepstone can be reached at: 1-800-289-6253 OR 1-203-270-0106 (Fax) -- The Stepstone Corporation Michael Goda 75 Glen Rd. mikeg@stepstone.com Sandy Hook, CT 06482 uunet!stpstn!mikeg (203) 426-1875 fax (203)270-0106 From jonas@his.UUCP Thu Apr 12 16:29:24 1990 From: jonas@his.UUCP (Jonas Mellin) Newsgroups: comp.lang.lisp Subject: CLOS Summary (LONG) Keywords: CLOS Date: 6 Apr 90 14:17:03 GMT Reply-To: jonas@his.UUCP (Jonas Mellin) Organization: Hogskolan i Skovde, Skovde, Sweden Status: RO Thanks to the following person I received information about CLOS: lgm@ihlpf.att.com (Lawrence G Mayka) barmar@news.think.com (Barry Margolin, Thinking Machines Corp) major@pyrmania.oz.au (Major) tmb@ai.mit.edu (Thomas M. Breuel) Tim Bradshaw <tim@cstr.ed.ac.uk> Here follows a summary of the replies and a few comments of my own: >I have heard that Common Lisp Object System should be a part of the >Common Lisp standard. I have tried to find it in various versions of >Common Lisp implementations and I have not found it. From: lgm@ihlpf.att.com (Lawrence G Mayka) CLOS has been voted into the draft ANSI Common Lisp standard, and is defined/described in Guy Steele's reference work, "Common Lisp: the Language - Second Edition," now available in (American) bookstores. The X3J13 Document 88-002R describes the specification of CLOS. There is also a book about CLOS called 'Object-Oriented Programming in COMMON LISP' by Sonya E. Keene, published by Addison Wesley >In which implementations of CL is CLOS a part of CL? From: barmar@news.think.com Symbolics Genera 8.0, being released in a month or so, includes CLOS. Lucid 4.0, currently in beta test, includes CLOS. From: lgm@ihlpf.att.com (Lawrence G Mayka) Essentially all commercial Common Lisp vendors are committed to supporting the CLOS standard; but if you want to know which implementations offer genuine, integrated, optimized CLOS *today*, I can think of the following: LispWorks from Harlequin Delphi CL from Delphi Procyon CL from ExperTelligence Ibuki CL from Ibuki TI CL from Texas Instruments IIM CL from Integrated Inference Machines Elis CL from Nippon Telegraph and Telephone Several caveats apply here, though: - I am not certain that every implementation listed has *fully* implemented and *significantly* optimized their CLOS. At the least, the vendors listed above support their CLOS implementation. - The three most "visible" American CL vendors - Symbolics, Franz, and Lucid - will probably release their own integrated CLOS implementations within the next six months. These three vendors are also the ones best supported by the Portable CLOS (PCL) available for free from Xerox PARC. >Any personal views of CLOS compared to Flavors. From: barmar@news.think.com CLOS uses generic functions (like New Flavors) rather than message sending, so it fits in with Lisp better (you don't always need to know that a particular operation is a generic operation). CLOS allows methods to be selected based on the types of more than one argument, not just the first argument. CLOS allows methods to be specialized on normal types, not just classes (e.g. you can write methods for INTEGER, NUMBER, SYMBOL, etc.). CLOS can be a little more cumbersome to program, though. Since methods aren't associated with a particular class they must use the WITH-SLOTS. From: lgm@ihlpf.att.com (Lawrence G Mayka) CLOS is more powerful than either Old or New Flavors, but its paradigm of method *applicability*, rather than the method *ownership* paradigm of more traditional OOPLs, takes some getting used to. CLOS does, however, beautifully integrate the object-oriented and functional programming paradigms. |>Is there a public domain version? How can I get it? From: barmar@news.think.com There's a public, portable implementation of most of CLOS, called PCL, available on Arisia.Xerox.COM. Macintosh Allegro CL currently includes this, and the version to be released later this year will include a nativ CLOS implementation. From: lgm@ihlpf.att.com (Lawrence G Mayka) PCL from Xerox PARC. You can get it via anonymous FTP from arisia.xerox.com as /pcl/tarfile . From: Tim Bradshaw <tim@cstr.ed.ac.uk> PCL, a free partial implementation of CLOS, is available by anonymous ftp from arisia.xerox.com. The current version (Rainy day) is known (by me) to compile and run on Franz Allegro CL, and Xerox Medley. I failed to compile it on Austin KCL (but I didn't try hard). From: major@pyrmania.oz.au (Major) PCL (Portable Common LOOPS) from Xerox is free and is slowly being permuted into CLOS. >From a document found in the PCL I found the following text: Portable CommonLoops (PCL) started out as an implementation of CommonLoops written entirely in CommonLisp. It is in the process of being converted to an implementation of CLOS. Currently it implements a only a subset of the CLOS specification. Unfortunately, there is no detailed description of the differences between PCL and the CLOS specification, the source code is often the best documentation. Currently, PCL runs in the following implementations of Common Lisp: EnvOS Medley Symbolics (Release 7.2) Lucid (3.0) ExCL (Franz Allegro 3.0.1) KCL (June 3, 1987) AKCL (1.86, June 30, 1987) Ibuki Common Lisp (01/01, October 15, 1987) TI (Release 4.1) Coral Common Lisp (Allegro 1.2) Golden Common Lisp (3.1) CMU VAXLisp (2.0) HP Common Lisp Pyramid Lisp A couple of methods to get PCL: *** Arpanet Access to PCL *** The primary way of getting PCL is by Arpanet FTP. The files are stored on arisia.xerox.com. You can copy them using anonymous FTP (username "anonymous", password "anonymous"). There are several directories which are of interest: /pcl This directory contains the PCL sources as well as some rudimentary documentation (including this file). All of these files are combined into a single Unix TAR file. The name of this file is "tarfile". Once you have untared the tarfile, the following files are of special interest: readme.text READ IT notes.text contains notes about the current state of PCL, and some instructions for installing PCL at your site. You should read this file whenever you get a new version of PCL. get-pcl.text contains the latest draft of this message /pcl/doc This directory contains TeX source files for the most recent draft of the CLOS specification. There are TeX source files for two documents called concep.tex and functi.tex. These correspond to chapter 1 and 2 of the CLOS specification. /pcl/archive This directory contains the joint archives of two important mailings lists: CommonLoops@Xerox.com is the mailing list for all PCL users. It carries announcements of new releases of PCL, bug reports and fixes, and general advice about how to use PCL and CLOS. Common-Lisp-Object-System@Sail.Stanford.edu is a small mailing list used by the designers of CLOS. The file cloops.text is always the newest of the archive files. The file cloops1.text is the oldest of the archive files. Higher numbered versions are more recent versions of the files. *** Using the BITFTP server at Princeton *** For people who can't FTP from Internet (Arpanet) hosts, but who have mail access to the BITNET, there exists a way to get the PCL files using the BITFTP service provided by Princeton Univerity. If you know exactly where to find the files that interest you, this is quite easy. In particular, you have to know: * the Internet host name of the host that maintains the files (such as `arisia.Xerox.COM') * the directory where to find the files, relative to the root of the FTP tree (i.E. `pub') * whether the files are binary or ASCII text. * the names of the files (say `pcl90.tar.Z' and `pcl90.README') To do this, send a message to BITFTP@PUCC (or BITFTP@PUCC.BITNET if you aren't on BITNET itself). The subject line of the message will be ignored. The text (body) of the message should be: FTP arisia.xerox.com UUENCODE CD pub CD pcl BINARY GET tarfile QUIT Then you wait (probably for about a day when you are in Europe) and eventually you will receive E-Mail messages from BITFTP@PUCC (or BITFTP2%PUCC...) with subject lines like `uudecoded file tarfile part 13'. Then you have to carefully concatenate the contents of ALL of these files in the correct order. Note: The following works on our Suns and should work on any Berkeley UNIX machine. If you don't have the `compress' or `zcat' program, you can get a free version (with MIT's X Window System distribution, for example). The resulting file can be `uudecode'd like this: dagobert% uudecode name-of-the-assembled-file This will give you a file tarfile.Z (it may actually have a different name; then you may want to rename it in the first place). The `.Z' at the end means that the file you now have is compressed. You can uncompress it with `uncompress tarfile. You can untar the uncompressed file with `tar xvf tarfile. This will write all files in the tarfile to the current directory. If you want to know more about the BITFTP service, send a letter to `BITFTP@PUCC' that contains the single line `HELP'. *** Xerox Internet Access to PCL *** Xerox XNS users can get PCL from {NB:PARC:XEROX}<PCL> Send any comments, bug-reports or suggestions for improvements to: CommonLoops.pa@Xerox.com Send mailing list requests or other administrative stuff to: CommonLoops-Request@Xerox.com HAPPY HACKING Disclaimer: Even a blind man may know how to C. _____________________________________________ / / / / /\ / / /| /| |E-mail: jonas@his.se / /--/ / \ / / / |/ | |UUCP: ...!sunic!his!jonas / / / / \/ / / / / | |Phone: +46 500 77646 /______________________/ \_/ onas / |ellin|Fax: +46 500 16325 Snailmail: Jonas Mellin,Hogskolan i Skovde, Box 408, 541 28 Skovde, Sweden From johani@nada.kth.se Sun Apr 15 15:47:34 1990 From: johani@nada.kth.se (Johan Ihren) Newsgroups: comp.lang.scheme Subject: Re: Portable object oriented scheme systems Date: 12 Apr 90 10:46:28 GMT Reply-To: johani@nada.kth.se (Johan Ihren) Organization: Royal Institute of Technology, Stockholm, Sweden Status: RO In article <RAIBLE.90Apr10173310@ew09.nas.nasa.gov> raible@orville.nas.nasa.gov writes: > >I'm interested in any portable object oriented systems for scheme, or >a non-portable one based on xscheme. Our SCIX system (an OO interface between Scheme and the X Window System) has a nice object oriented system, designed by Magnus Persson, Digital, in it. It supports muliple inheritance, inheritance of instances (i.e. not just of classes), dynamic insertion, deletion and renaming of methods, optional per-method resolution of message name collisions and other things one might expect from an OO system. It is perfectly possible to use HWOOPS separately from SCIX. The only thing needed is the extend-syntax macro mechanism available in some Scheme systems (notably Chez Scheme). The source to extend-syntax has been made freely available by its author, Kent Dybvig, and therefore it has been ported to several Scheme systems without native extend-syntax support. We have ported it to the Scheme->C system ourselves. We designed HWOOPS with extend-syntax and then built SCIX upon HWOOPS. The HWOOPS subsystem is available in the SCIX distribution which can be found on expo.lcs.mit.edu:~ftp/contrib/scix-0.96.tar.Z. All you really need is a few files, but there is no separate distribution of HWOOPS right now. Of course it is also possible to get it directly through me. Johan Ihren Dept. of Computer Science, Royal Institute of Technology, Stockholm, Sweden Email: johani@nada.kth.se -or- <backbone>!sunic!nada!johani From briscoe-duke@CS.YALE.EDU 24 Apr 90 16:40:30 GMT Path: aber-cs!gdt!dcl-cs!ukc!mcsun!uunet!snorkelwacker!think!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv From: briscoe-duke@CS.YALE.EDU (Duke Briscoe) Newsgroups: comp.archives Subject: Re: looking an ftp site for scheme [scheme] Message-ID: <11803@stag.math.lsa.umich.edu> Date: 24 Apr 90 16:40:30 GMT Sender: news@math.lsa.umich.edu Reply-To: briscoe-duke@CS.YALE.EDU (Duke Briscoe) Followup-To: comp.lang.scheme Lines: 24 Approved: emv@math.lsa.umich.edu (Edward Vielmetti) X-Original-Newsgroups: comp.lang.scheme Status: RO Archive-name: t3.1/24-Apr-90 Original-posting-by: briscoe-duke@CS.YALE.EDU (Duke Briscoe) Original-subject: Re: looking an ftp site for scheme Archive-site: wheaties.ai.mit.edu [128.52.32.13] Archive-directory: pub/t3.1 Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) The T language includes an environment for Scheme, and from my experience I judge it to be at least 99% conformant to the Scheme standard, and there isn't any performance penalty for using T to run Scheme since the Scheme environment just allows a different set of names to be used for the underlying T functions. T also provides some useful extensions to Scheme. T has an optimizing compiler, and best of all it is available by anonymous ftp from wheaties.ai.mit.edu (128.52.32.6) in the pub/t3.1 directory. That directory contains binaries and sources for T3.1. Currently available versions are for Dec3100(pmax), Sun4(sparc),Sun3, Vax/Unix, Encore, Hp workstation, Apollo and Mac/Aux. The online version of the T manual is also there as well as release notes for T3.0 and T3.1. For Sun and Vax there is a C/Unix interface to T. From masala.lcs.mit.edu (18.27.0.200) in the pub directory you can get a T dialect extended for parallelism (uses the future construct) called Mul-T; it runs on the Encore Multimax. From bader+@ANDREW.CMU.EDU Tue Jun 26 21:02:01 1990 From: bader+@ANDREW.CMU.EDU (Miles Bader) Newsgroups: comp.archives Subject: oopc v3 [andrew] Date: 20 Jun 90 01:10:37 GMT Reply-To: bader+@ANDREW.CMU.EDU (Miles Bader) Followup-To: comp.soft-sys.andrew Organization: University of Michigan, Department of Mathematics X-Original-Newsgroups: comp.soft-sys.andrew Status: RO Archive-name: oopc/19-Jun-90 Original-posting-by: bader+@ANDREW.CMU.EDU (Miles Bader) Original-subject: oopc v3 Archive-site: woodstock.andrew.cmu.edu [128.2.30.38] Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) I've made the next version of oopc (3.0) available for anonymous ftp from woodstock.andrew.cmu.edu, as "oopc.jun19.tar.Z". Changes include the previously mentioned namespace ones, removal of some class compatibility code, and a new "dynamic library" scheme (which removes the need for redundant code in dynamic objects). Look at README to see how to compile it. -Miles From dietrich@quando.quantum.de Mon Jun 25 08:27:01 1990 From: dietrich@quando.quantum.de (Hans Dietrich) Newsgroups: comp.sys.atari.st,comp.object,comp.lang.smalltalk Subject: Re: OO on ST (long) Summary: Use SIMULA! Keywords: OOP, SIMULA, Atari ST Date: 22 Jun 90 09:11:17 GMT Reply-To: dietrich@quando.UUCP (Hans Dietrich) Organization: Quantum GmbH, Dortmund, W-Germany Status: RO In article <8480@cognos.UUCP> rossj@cognos.UUCP (Ross Judson) writes: >I've been toying with a few ideas for my honours project, which I'll >be doing next year. Since my school's faculty is really into OO >stuff, I'll be doing something in that area. What OO environments are >available on the ST? Do any of them work? Are any of them suitable >for project-style work? Projects usually take about 8 months to do, >and are supposed to be a reasonably sophisticated implementation of >whatever your project is about. > >My system is a 1040 with a 30MB. I'm willing to upgrade the memory, >but given my faith in the world of Atari I'm not so sure I want to >invest more. > [ ... ] What's about the first object oriented language - SIMULA - as an alternative ? It's still up to date, and can run on simple 1040 ST with one disk drive!! I append an abstract about the system from the SIMULA-Team in Germany. The contact address is included at the end. Here it is: --------------------------------------------------------------------- SIMULA for Atari ST If you want to do object oriented programming you definitely should have a look at SIMULA. SIMULA is the first and still the most advanced object oriented programming language available on a wide variety of machines *including* the Atari ST (see below). SIMULA in a nutshell ==================== o Conventional general-purpose algorithmic capability in the style of ALGOL 60. o Object-oriented programming (classes) encompassing encapsulation, inheritance, information hiding, autonomous activity and strong typing supporting the concepts of modularisation, generalisation, specialisation, abstraction, polymorphism and pseudo-parallelism. o Basic features for manipulating text strings. o File concept supporting sequential and direct access methods for byte- and record-structured files. o Large repertoire of utility functions. o Features supporting 2-way linked lists. More complicated list structures such as trees and lattices are easily constructed from the basic class facilities. o Features supporting discrete event simulation in various styles including the object-oriented process view. It should be emphasised that although in many quarters SIMULA is best known for its simulation features it is a truly general- purpose language in the widest sense and was the inspiration for almost all developments in the field of object-oriented programming. What you get with each SIMULA system ==================================== o Object oriented programming. A typical SIMULA program consists of a set of interacting processes or *objects*. Objects are incarnations of some prototype or *class*, generated (and later perhaps terminated) during the execution of the program. In this manner a program written in SIMULA may map the problem solution conveniently and cleanly. o Strong typing, checked mostly at compile time, ensuring that objects are manipulated in a manner consistent with their specification. o Objects may act independently of each other in "quasi- parallel". This enables the class objects to act as coroutines, so that the action of one object may be temporarily suspended, later to be resumed at the exact point of suspension. Coroutines facilitate a faithful representation of systems composed of both passive and active objects. This feature is an extra dimension to those commonly associated with object-oriented languages and is only recently beginning to appear in some of the newer ones. o List processing. The class "Simset" may be applied to add list processing capabilities to the language. The programmer will then have tools for the efficient manipulation of common aggregate information structures, including queues. The facilities of Simset can be further refined for more specialised purposes. o Simulation. Application of the built-in class "Simulation" extends SIMULA to a powerful tool for discrete event simulation in a style which preserves in the model the inherent structure of the system under study. o Powerful text handling, dynamic arrays, flexible file handling, etc. o Modularisation. Separate compilation of classes and procedures is an integral part of the language. The strong typing extends to separately compiled modules allowing the partitioning of large SIMULA systems into subtasks, which may be assigned to different work groups, without fear of undetected incompatibilities. o SIMULA has a rigid standard definition and programs are highly portable between different computer systems (source code compatibility). Some properties of the SIMULA system for the Atari ST ===================================================== o Full SIMULA language standard. (Currently the only restriction is that the switch is not yet implemented. Also you might expect a better accuracy from software emulation for real arithmetic.) o Implementation based on the well-known Lund SIMULA System for UNIX machines and others. o Compact implementation. The complete system fits on one double-side disk. o Economic. The compiler needs less than 1 MB even when compiling modules consisting of more than one thousand source lines. o Fast. Compilation speed of approximately 1000 source lines per minute. The execution speed is comparable with that of other high-level languages. o Complete interfaces to TOS and GEM. o Separate compilation of different modules with consistency checks at compile time. o Compatibility. Runs on all TOS versions and all types of keyboards. Call interface for external procedures written in other languages (currently supported: assembler - under development: C). Uses Sozobon's jas and ld, alternatively Atari's MadMac and aln (on request also GST). o Symbolic debugger (source-code debugger) is under development. Ordering information ==================== Atari ST SIMULA is distributed by: SIMULA-Team GmbH iG P.O.B. 50 01 63 D - 4600 Dortmund 50 West - Germany The introductory prices are (prices in US$ and GBP at current exchange rates, for information only): DM US$ GBP ordinary 198,- 120,- 72,- educational 148,- 90,- 54,- (for students, teachers etc. - please accompany your order with an evidence) delivery charge in Germany, prepaid 7,- delivery charge in Germany, not prepaid 12,- delivery charge abroad, prepaid 22,- 13,- 8,- (this charge is waived if you can do without the German documentation) Please accompany your order with a cheque payable in DM to SIMULA-Team GmbH Dortmund or transfer the amount due in DM before ordering to PostGiroAmt Dortmund (BLZ 440 100 46) Account 8999-466 for O. Schlageter Computer Literature ========== The Standard: [SIS87] SIMULA Standard. Stockholm, 1987. Data processing - Programming languages - SIMULA, Swedish Standard SS 63 61 14. Textbooks on SIMULA: [BDMN73] Graham M. Birtwistle, Ole-Johan Dahl, Bjoern Myhrhaug, and Kristen Nygaard. SIMULA BEGIN. Studentlitteratur, Lund, Sweden, 1973. ISBN 91-44-06211-7. Also published by Bratt Institut fuer neues Lernen, Goch, GDR and Chartwell-Bratt Ltd., Bromley, England. [Jed86] P. Jedlovzky. Do it with SIMULA. COMPUDRUG International, Laxenburgerstr. 49/7/15, A-1100 Wien, Austria, 1986. [Poo87] R. J. Pooley. An Introduction to Programming in SIMULA. Blackwell Scientific Publications, Oxford, 1987. ISBN 0-632-01611-6 resp. 0-632-01422-9 (pbk.). [Lam88] Guenther Lamprecht. SIMULA - Einfuehrung in die Programmiersprache. Vieweg Verlag, Braunschweig, Wiesbaden, 3. neubearbeitete Auflage, 1988. ISBN 3-528-23321-4. (In German, also available in English) [Kir89] Bjoern Kirkerud. Object-Oriented Programming with SIMULA. International Computer Science Series. Addison- Wesley Publishing Co., 1989. ISBN 0-201-17574-6. Textbooks on Simulation: [Fra77] W. R. Franta. The process view of simulation. Elsevier North-Holland, New-York, 1977. Also published by North- Holland, Netherlands. [Bir79] Graham M. Birtwistle. DEMOS - Discrete Event Modelling on SIMULA. MacMillan Press, London, Basingstoke, 1979. ISBN 0-333-32881-8. [Mit82] I. Mitrani. Simulation Techniques for discrete event systems. Cambridge University Press, 1982. [Kre86] Wolfgang Kreutzer. System Simulation Programming Styles and Languages. Addison-Wesley Publishing Co., 1986. SIMULA - Implementations ======================== SIMULA is available for the following computer systems: Apollo DN3000 Apple MacIntosh/MPW Atari ST BESM 6 (USSR) CDC 3000, CDC 6000/Cyber Cromemco CS-x00 DEC 10/20 DG Eclipse/Desktop, DG MV EC 1040/1055 (GDR) ES EVM (USSR) Honeywell Bull DPS8 HP 900/300, HP 9300 IBM mainframe IBM PC/DOS, IBM PC/OS2, IBM PC/XENIX(UNIX) ICL 2900, ICL PERQ Indata IN4200 Masscomp NCR Minitower, NCR Tower XP/32 Nixdorf Targon/31 Norsk Data NORD 100/500 PR1ME SIEMENS 7500/BS2000, SIEMENS 7800/BS3000 SIEMENS MX, SIEMENS PCD Sperry 1100 SUN-3, SUN-4 (SPARC) VAX/UNIX, VAX/VMS Since there are new implementations under way this list may be already incomplete. More information on SIMULA ========================== Association of SIMULA Users (ASU) Secreteriat Ron Kerr Computing Laboratory University of Newcastle upon Tyne Newcastle upon Tyne NE1 7RU England Telephone: (+44 91) 222 8187 e-mail: r.kerr@newcastle.ac.uk The ASU also publishes a Newsletter which may be subscribed (still) free of charge. Contact for SIMULA in Germany: SIMULA Group c/o University Dortmund / IRB P.O.B. 50 05 00 D - 4600 Dortmund 50 West - Germany e-mail: simula@unido.uucp simula@unido.bitnet ------------------------------------------------------------- I hope this helps! best regards, Hans Dietrich ============================================================= SIMULA does is with class ! ============================================================= From creemer@ohm.sw.mcc.com Thu Jun 28 14:36:31 1990 From: creemer@ohm.sw.mcc.com (David Z. Creemer) Newsgroups: comp.archives Subject: Re: ftp location for xscheme source? [scheme] Keywords: not c-scheme Date: 27 Jun 90 18:48:37 GMT Reply-To: creemer@ohm.sw.mcc.com (David Z. Creemer) Followup-To: comp.lang.scheme Organization: University of Michigan, Department of Mathematics X-Original-Newsgroups: comp.lang.scheme Status: RO Archive-name: xscheme/27-Jun-90 Original-posting-by: creemer@ohm.sw.mcc.com (David Z. Creemer) Original-subject: Re: ftp location for xscheme source? Archive-site: terminator.cc.umich.edu [35.1.33.8] Archive-directory: msdos Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) Some weeks ago I too went on a hunt for the latest XScheme. I found it on the M & T Listings Service BBS, (415)-364-8315. This is apparently the initial distribution point, and also contains discussion threads with David Betz (xscheme's author). The latest source is 0.22. I received some information that 0.24 was now available, but I couldn't find it on the BBS, so for now XScheme 0.22 is it. I posted it for anonymous ftp to terminator.cc.umich.edu (35.1.33.8). It's in the msdos directory. #t -- David David Creemer | MCC Software Technology Program | creemer@mcc.com 512 338-3403 | 3500 W Balcones Center Dr., Austin, Texas 78759-6509 From huss@nada.kth.se Wed Jul 18 22:34:31 1990 From: huss@nada.kth.se (H}kan Huss) Newsgroups: comp.lang.scheme,comp.windows.x Subject: Announcing the release of SCIX version 0.97. Date: 16 Jul 90 18:51:39 GMT Reply-To: huss@nada.kth.se (H}kan Huss) Organization: Royal Institute of Technology, Stockholm, Sweden Status: RO We are pleased to announce the public release of SCIX version 0.97. It is available for anonymous FTP at ftp.kth.se in the directory pub/Xcontrib/Toolkits/Scix and it will also be put on expo.lcs.mit.edu in the contrib directory as soon as we can reach it. The files involved are scix.README (short description of the system), scix-0.97.tar.Z (the system) and scix-report.ps.Z (a technical report describing the system.) This version differs from 0.96 mostly in that several bugs have been fixed. The following is the scix.README file: SCIX -- A Scheme Interface to the X Window System The file scix-0.97.tar.Z contains the entire source for the SCIX system. SCIX is a completely object-oriented interface between the X Window System and the programming language Scheme. It is currently at version 0.97, i.e., it is a beta release. It has been implemented with the Scheme->C system developed at Digital Western Research Laboratory in Palo Alto by Joel Bartlett (Scheme->C is available by anonymous ftp from gatekeeper.dec.com [16.1.0.2]). A consequence of this is that SCIX is currently only working on architectures that Scheme->C works on (today this is DECstations, VAXes, Sun3, Sun386 and Sparc). SCIX has been thoroughly tested on DECstations and Sparcs. Both SCIX and Scheme->C should be rather easy to port. Most of the SCIX system is written in standard Scheme (according to the R^3.99RS). A few low-level routines are written in C. No programming libraries (like Xlib or Xt) are used to generate SCIX, but some include files from the X distribution are. The added functionality is primarily described in our report, the PostScript source of which is available in the file scix-report.ps.Z. A few sample demonstrations are provided with the system. To install, SCIX needs approximately 10 Mb of disk space. The built system consists of a SCIX interpreter of 1.8 Mb (including demos), and two libraries taking up less than 2 Mb. A minimal interpreter is just below 1 Mb in size. The entire SCIX system was developed by us as the subject of our masters thesis. The project was initiated, advised, and sponsored by Magnus Persson at Digital Equipment AB, Sweden. Hakan Huss and Johan Ihren <huss@nada.kth.se> and <johani@nada.kth.se> Department of Computing Science (NADA), Royal Institute of Technology (KTH), Stockholm, Sweden From hoelzle@Neon.Stanford.EDU Sun Jul 29 20:24:26 1990 From: hoelzle@Neon.Stanford.EDU (Urs Hoelzle) Newsgroups: comp.archives Subject: SELF [comp.object...] Date: 26 Jul 90 04:26:25 GMT Reply-To: hoelzle@Neon.Stanford.EDU (Urs Hoelzle) Followup-To: comp.object,comp.lang.smalltalk,comp.lang.misc Organization: University of Michigan, Department of Mathematics X-Original-Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.misc Status: RO Archive-name: self/21-Jul-90 Original-posting-by: hoelzle@Neon.Stanford.EDU (Urs Hoelzle) Original-subject: SELF Archive-site: otis.stanford.edu [36.22.0.201] Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) Announcing Self Release 1.0 The Self Group at Stanford University is pleased to announce the first distribution of the experimental object-oriented exploratory programming language Self. Designed for expressive power and malleability, Self combines a pure, prototype-based object model with uniform access to state and behavior. Unlike other languages, Self allows objects to inherit state and to change their patterns of inheritance dynamically. Self's virtual machine includes a customizing compiler that (to the best of our knowledge) makes this the fastest implementation of any dynamically typed, object-oriented language. This release, which runs on Sun3's and Sun4's, is available free of charge from: David Ungar The Self Group CIS, Room 209 Stanford University Stanford CA 94305 or: self-request@self.stanford.edu The documentation consists of two 100-page books: a collection of technical papers and a set of three manuals. PostScript versions of the documentation are available via anonymous ftp from otis.stanford.edu (36.22.0.201). If you would like hardcopy, please send $20 (made out to Stanford University) to the above address (send mail to self-request for overseas rates). To obtain Self via ftp, please complete the form below and send it to us via PHYSICAL mail; e-mail requests cannot be honored. You will receive an acknowledgement by e-mail when your account has been opened. If you have questions or need the software on tape, write to self-request@self.stanford.edu. Finally, there is a mail group for those interested in random ramblings about Self, self-interest@self.stanford.edu. Send mail to self-request@self.stanford.edu to be added to it. ----------------------------- cut here ----------------------------- To: David Ungar The Self Group CIS, Room 209 Stanford University Stanford, CA 94305 Re: Transfer of Computer Software Please make available to me the computer software known as Self, Release 1.0, that was developed at Stanford University in the Computer Science and Electrical Engineering Departments by the Self Group: David Ungar, Craig Chambers, Bay-Wei Chang, and Urs Hoelzle. I understand that the software is being provided on an `as is' basis for my non-commercial research purposes. I will not distribute the software, or any portion or derivative thereof, beyond my organization without your written consent. I understand that the software is provided to me without warranties of any kind and with no provisions for support or future enhancements. I also understand that neither The Self Group nor Stanford University or any of its employees have any liability in connection with the use of the software. I agree with the above and would like you to open a temporary account for me to transfer the software. I agree not to use this account for any other purpose, and not to make it available to any other person. AGREED AND ACCEPTED: Name: Address: e-mail address: Desired account name: Desired password (at least 6 characters long): Date Signature From gza@mentor.cc.purdue.edu Sun Apr 1 19:46:45 1990 From: gza@mentor.cc.purdue.edu (William R Burdick) Newsgroups: comp.lang.smalltalk,comp.object,rec.games.programmer,rec.arts.int-fiction Subject: mob, a FREE OOPL based on Smalltalk (LONG) Summary: a description of the language Keywords: oo object-oriented mob smalltalk mud free Date: 21 Mar 90 05:45:59 GMT Followup-To: comp.object Organization: Team Cthulhu Status: RO I've had enough requests for info on mob that I figured I should post this. PLEASE note that mob isn't available, yet. Version 1.0 will be ready by May, or so. ------------------------------------------------------------------------------ Mob, the language Mob is an object oriented language that we (TEAM CTHULHU) have been developing at Purdue University for the last couple years. We have been working on it specfically for having a language to implement multi-user adventure games, but there is no reason it should be limited to such. After a dozens of revisions (and many base languages) mob has settled down to be a super-set of Smalltalk. The syntax is identical to Smalltalk except for changes made to support multiple inheritance, forwarders, and our primitive methods to interface with C. There are also a couple of new conventions and features we use. Mob does not stand for anything really, and is normally all lowercase, unless it's at the beginning of a sentence. This is the current grammar: program: header methods classMethods footer ; header: className 'is' superclasses iVars cVars cIVars; className: IDENT ; superclasses: idents ; idents: IDENT ; idents: IDENT idents ; footer: 'end' className ; /* this should be the same as the first token */ iVars: ; iVars: 'instVars' varNames ; varNames: idents ; cVars: ; cVars: 'classVars' varNames ; cIVars: ; cIVars: 'classInstVars' varNames ; locals: ; locals: 'localVars' varNames '.'; methods: ; methods: method methods ; method: permission 'method' msgHdr '.' locals optstatements ; method: 'method' '@' className msgHdr ; /* className must be a direct superclass */ method: 'protocol' stringList ; method: 'require' className ; method: 'globalVars' varNames ; method: 'primitive' msgHdr '.' cfuncName ; classMethods: ; classMethods: 'classMethods' methods ; permission: ; permission: 'private' ; permission: 'subclass' ; cfuncPart: '_' ; cfuncPart: UNARY ; cfuncName: cfuncPart ; cfuncName: cfuncPart cfuncName ; msgHdr: UNARY ; msgHdr: BINARY varName ; msgHdr: infixMsgHdr ; infixMsgHdr: INFIX varName ; infixMsgHdr: INFIX varName infixMsgHdr ; optstatements: ; optstatements: statements ; statements: statement ; statements: statement '.' statements; statement: expr ; statement: '^' expr ; expr: infixExpr messageList ; expr: IDENT '<-' expr ; messageList: ; messageList: ';' message messageList ; message: infixMessage ; message: binaryMessage ; message: unaryMessage ; infixExpr: binaryExpr ; infixExpr: binaryExpr infixMessage ; infixMessage: INFIX infixExpr ; binaryExpr: unaryexpr ; binaryExpr: unaryexpr binaryMessage ; binaryMessage: BINARY unaryExpr ; binaryMessage: BINARY unaryExpr binaryMessage; unaryExpr: primaryExpr ; unaryExpr: primaryExpr unaryMessage ; unaryMessage: IDENT ; unaryMessage: IDENT unaryMessage ; primaryExpr: constant ; primaryExpr: lambda ; primaryExpr: IDENT ; primaryExpr: 'self' ; primaryExpr: 'realSelf' ; primaryExpr: 'super' ; primaryExpr: 'super' '@' className ; /* className must be an immediate super class */ primaryExpr: '(' expr ')' ; primaryExpr: '#' constantList ; primaryExpr: '#' symbol ; constant: 'nil' ; constant: 'true' ; constant: 'false' ; constant: FLOAT ; /* [0-9]*.[0-9]* */ constant: INT ; /* [0-9]* */ constant: '$' CHAR ; /* '$$' would be a single '$'. No whitespace after the '$' unless you mean a whitespace character. */ constant: stringList ; stringList: STRING ; stringList: STRING stringList ; lambda: '[' varDecs statements ']' ; varDecs: ; varDecs: decVars '|'; decVars: ':' IDENT ; decVars: ':' IDENT decVars ; symbol: UNARY ; symbol: BINARY ; symbol: SYMBOL ; symbol: INFIX ; constantPart: constantList ; constantPart: constant ; constantPart: symbol ; constantList: '(' className '_' constantParts ')' ; constantList: '(' constantParts ')' ; constantParts: ; constantParts: constantPart constantParts ; ASSIGNMENT OPERATOR Smalltalk uses an underbar character for the assignment operator, (which appears as a left arrow with their font). In mob, we use two characters <- for this operator. "SAYING" OBJECTS As in Smalltalk, mob has a method of 'saying' arrays in a file, like this: #(a b c) yeilds an array of the symbols: #a, #b, #c. You cannot put variables in here, only constants and other 'sayings.' One modification to Smalltalk's representation is that you can say: #(LinkedList _ a b c) to make an instance of LinkedList. This really sends a message to LinkedList called given:, with an array of the elements as an argument. In order for this to work, LinkedList must already be defined, of course, so it is possible to 'say' ambiguous things this way. Note that using a class while you are 'saying' an object automatically 'requires' that class (see REQUIRE below). MULTIPLE INHERTANCE The concept of multiple inheritance seems easy enough at first, but it does throw a monkey wrench into things. The basic idea is that you inherit the instance variables and methods from all of your parents. Obviously, name conflicts may arise. If one or more of your parents define a method, you inherit one at RANDOM, unless you specify which one you want to inherit (via the @ declaration of a method). If you want to call the code defined in more than one, you must make a new method to do this. If there is a conflict in instance variables this is an error condition. If your parents have the same instance variable because they inherited it from the same class, this is NOT an error. The before and after methods are for multiple inheritance. Before will call the method as defined in your superclasses. It is guaranteed to call your ancestors' methods in a depth-first search, it will never execute a method more than once during a particular invokation. This guarantees that a method which overrides an ancestor's method (ie. has the same name) will be invoked BEFORE the overridden method. After is defined to call the supers first. The order of invokation is likewise guaranteed; a method which overrides an ancestor's method will be invoked AFTER the ancestor's method (the call looks like this: 'self before'). Before and after use an inheritance list which is generated by the compiler when the class is defined. Before and after can be crucial in defining methods where multiple unwanted invokations of an ancestor's method would arise from simple invocation of superclass methods due to multiple inheritance. For example, in the given class tree: Object / \ Human Gender | / \ | Male Female \ / Man Every class present has an initialize method. The method in Man will want to call initialize defined in Human, and in Male, but both of these (probably) call initialize in Object. For the sake of argument, assume Object has an instance variable called 'count'. Human, Gender, and Male will all inherit this in the same manner as single inheritance. Man will also inherit refCount. Although Human and Male both have the same variable, they inherited it from a common ancestor (Object) so there is no error. The class files for Object, Gender, Male, and Man are given below: (All methods other than initialize are deleted for brevity). Object is Root instVars count method initialize. self count: 1 "although calling this method more than once is harmless" "in some cases it might not be" end Object Gender is Object instVars sex. method initialize. super initialize. self sex: 'neuter' end Gender Male is Gender method initialize. self after. self sex: 'male' end Male Human is Object instVars name. method initialize. self after. self name: 'I have no name' end Human Man is Human Male instVars age. method initialize. "I call all my supers in this order:" "Human Male Gender Object" "The initialize in Object will be called ONCE, even though" "Human and Gender both make calls to it, afterwards I execute:" self after. self age: 0 end Man There are extensions to the before and after methods, to allow control over the business of method invokation. They are: beforeDo: [:class :returnVal | <stuff>] afterDo: [:class :returnVal | <stuff>] After each method executes, these execute their blocks with the return value of the method and the class where the method is defined. beforeIf: [:class | <conditional stuff>] do: [:returnVal | <stuff>] afterIf: [:class | <conditional stuff>] do: [:returnVal | <stuff>] These behave the same way, except that they execute the method only if the conditional stuff yields a true value. FORWARDERS Forwarders are a concept we decided to use a year or so ago. To really implement magic in an adventure game, you need to have a hook into virtually every single method, so spells can wedge themselves anywhere in the universe. Forwarders are our solution to this problem, you can add a hook to ANY method(s),for one specific object (called the target), and do this at RUN time. The overhead occured with the hook will only be incurred if the target gets a message, unlike in a totally compiled environment, where the hook may have to be checked for each function call. Forwarders are instances of a descendant of the Forwarder class. They work by setting an instance variable to point to the target object, and then 'become:'ing the target. Every other object in mob that used to point to the target now points to the forwarder instead. The mechanism is totally transparent. Now the forwarder has its doesNotUnderstand: method defined to pass the message to the target by default. Forwarders that want to do something interesting can check the message first and do anything it likes with it, ignore it, change the arguments, etc. The kernel actually keeps track of two 'self's for every object, called 'self' and 'realSelf'. When a forwarder is attached to an object, that object's self is changed to point to the forwarder. If you put another forwarder on top, you can form a chain. The 'self' keyword yeilds 'self,' and the 'realSelf' keyword yields 'realSelf'. RealSelf is only used internally by forwarders when they need to fiddle with themselves and also by a few methods defined in Object. Instances of primitive classes (like Integer) do not have mob selves, and hence may not have forwarders placed on them. The reason forwarders break in Smalltalk is that there is no redirectable self. This causes forwarders to be excluded from messages which an object sends to itself and results in inconsistent and unexpected behavior. The tricky thing you can do in Smalltalk to implement consistent forwarders is to define a variable to hold the virtual self in Object and replace all occurrences of self (except in a few methods) in all methods defined for 'complex objects' (ie. not symbols, numbers, (or other things which are copied when they are passed as arguments to methods) with the accessing method for that variable. So Smalltalk could conceivably do forwarders right, but you'd have to edit virtually every method already in the system to insure that they behave right. ACCESSING METHODS You should NEVER access an instance variable directly, NOT EVEN IN METHODS DEFINED IN THE SAME CLASS WHICH DEFINES THE VARIABLE. You should always pass a message to retrieve or change its value! The two exceptions are the methods for setting and getting the variables' values (You have to define the accessing method somehow...). Doing otherwise will break forwarders, since you will be circumventing the forwarder's 'hook'. It will probably break your code too. The evil thing about this is that the code will probably break in a subclass which you didn't think about while you were writing the original class, not in the class which defined the instance variable. This convention is not, however, currently enforced by the language, but it is so important, that it may well be. AUTO-GENERATED ACCESSORS For lazy people (like us), mob will automatically generate accessing methods for instance variables if the programmer doesn't provide the methods him/herself. This also removes any excuse for not passing messages to use variable. In the examples above for the Human class, the two methods age and age: would be automatically defined: method age. ^age method age: newAge. age <- newAge METHODS RETURN SELF BY DEFAULT As in Smalltalk, unless a method explicitly returns a value, self is returned. STRING CONCATENATION As apparent from the grammar, adjacent constant strings are automatically concatenated by the parser. Hence, 'hello ' 'world' is identical to 'hello world' Whitespace is entered in the same form as C, \n = newline, \r = return, \b = backspace, \t = tab, and \v = vertical tab (\\ = backslash). REQUIRE <CLASSNAME> Any time you wish to refer to a class by its name, you must have a require statement in the file at some point before the reference. This is an equivalent to extern or importing, and is used to help insure that your programs work. All of your super classes are automatically 'required'. If you include all the necessary require directives, you will only have to explicitly load one file into the mob environment. PROTOCOL <subject> Protocol statements are entirely optional, and are only used by a browser to group related methods. Their use is STRONGLY encouraged. PRIMITIVES Primitives are naturally tricky little beasts, and I will refrain from explaining how to write these. When the language is released, it should not be necessary for a normal user to mess with them. They will however, be explained in the release. METHOD SECURITY You can limit which objects may invoke a method by declaring methods to be 'private' or 'subclass.' An object only understands a private method if it itself is invoking the method and its class is the same as the one where the method was defined (ie. it isn't a subclass of that class). An object only understands a subclass methods if it itself is invoking the method. If another object sends a message for a private or subclass method to another object, that object will not understand it. If an object sends a message for a private method to itself, but that private method is defined in a superclass, it will not understand the method. Method security is used for explicitly designating which methods may be used and which are 'implementation dependent.' ---------------------------------------------------------------------- Team Cthulhu: (The mentor accounts are only until May '90) Mitch Adler g1w@mentor.cc.purdue.edu Bill Burdick burdick@carame.ecn.purdue.edu Roy Riggs gp5@mentor.cc.purdue.edu -- -- Bill Burdick burdick@cello.ecn.purdue.edu -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
fmhv@inesc.UUCP (Fernando Manuel Hourtiguet de Vasconcelos) (09/24/90)
In article <BRUCEC.90Sep17112957@phoebus.phoebus.labs.tek.com>, brucec@phoebus.phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) writes: > In article <77500057@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu writes: > > > > I like to use Smalltalk to teach object-oriented programming because > > the class library makes a great set of examples. The programming > > environment makes programming fun, which always helps a class. On the > > other hand, lots of other o-o languages come with good class libraries > > and a nice programming environment. Unfortunately, C++ is not one of > > them. > > > > There's an additional reason for learning the basics of OOP from Smalltalk > (or rather, not from C++): the model is clean and easy to see and > understand. Everything is an object; there aren't any special cases, and > there isn't a lot of hairy syntax. > > I learned Smalltalk first, so that when I came to C++ I understood the > basic concepts, and could concentrate on learning the complexities of the > language. [... text deleted ] In agree entirely with Bruce's view on the subject, having followed exactly the same path ( Smalltalk -> C++ ). The two main things that I liked in Smalltalk ( as a concept learning language - I mean the OO paradigm ) were: - The model being so clean ( everthing is an object ... ) - The environment itself wich procteted me of the machine details that are not relevant when trying to learn a new concept. I mean by this questions like: how to compile, which editor to use .... This two reasons ( specially the last one ) make me think that Smalltalk is the ideal language to teach the OO paradigm, because pupils will concentrate on the language and it's concepts. ( Eventualy they would not have to know which OS they working with :-) ) -------------------------------------------------------------------------------- Fernando Vasconcelos INESC - Intituto de Engenharia de fmhv@inesc.inesc.pt Sistemas e Computadores mcsun!inesc!fmhv@uunet.uu.net Rua Alves Redol No 9 Tel: +351(1)545150 Ext. 216 1017 Lisboa CODEX - Portugal Fax: +351(1)525843 Sala 208