ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/16/90)
Category 18, Topic 69
Message 82 Sat Sep 15, 1990
GARY-S at 07:24 EDT
Perhaps it might be to everyone's mutual advantage to determine where
agreement and common ground may be found in this Object Oriented
discussion. Perhaps it might even be worthwhile to quantify the basic
concepts of just 'what is Object Oriented Programming'.
Tim Korson and John D. McGregor in CACM, Vol 33, No 9, pp 38...
maintain there are but five concepts that clearly define Object Oriented
Programming. These are as follows:
o Objects - the basic run time entities that occupy memory and
have an associated address
o Classes - a set of possible objects, ideally with implementation
details unique to the class
o Inheritance - relation between classes that allows for the definition
and implementation of one class to be based on that of
existing class(es)
o Polymorphism - the ability to take more than one form. In OOP this
means the a polymorphic reference may, over time, refer
to more than one class
o Dynamic Binding - in essence, the nature of a proceedure call is not
known (predefined) until the moment of call at runtime
Korson and McGregor further maintaion of the five concepts only one,
inheritance, is a unique contributor of the paradigm.
Do all the contributers to the OOP/OOF discussion (?) in c.l.f. find the
above reasonable and acceptible basic principals ?
Gary
___ _ (Gary Smith)texbell!attctc!blackbox!bl133!lrark!glsrk!gars *
/ _' _ _ (_' P. O. Drawer 7680 * GEnie Forth RT & Unix RT SysOp *
/__/ (_|_/ '._) Little Rock,AR 72217 * winken!well!gars * claris!wet!gars *
gars@glsrk.uucp - U. S. A. - * ames!chinet!gars * ph:501-227-7817 *
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usgarym@cognos.uucp@uunet.uu.net (Gary Murphy) (09/21/90)
Anyone who has read the comp.object groups will recognize this thread
as an endless one -- there is no clear consensus on what OOP means, only
a few loose definitions of OOP languages. The list presented does outline
most of the features advertised in other OOP systems, namely...
>>>>> On 16 Sep 90 01:40:23 GMT, ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) said:
FN-> Tim Korson and John D. McGregor in CACM, Vol 33, No 9, pp 38...
FN-> maintain there are but five concepts that clearly define Object Oriented
FN-> Programming. These are as follows:
FN-> o Objects - the basic run time entities that occupy memory and
FN-> have an associated address
FN-> o Classes - a set of possible objects, ideally with implementation
FN-> details unique to the class
FN-> o Inheritance - relation between classes that allows for the definition
FN-> and implementation of one class to be based on that of
FN-> existing class(es)
FN-> o Polymorphism - the ability to take more than one form. In OOP this
FN-> means the a polymorphic reference may, over time, refer
FN-> to more than one class
FN-> o Dynamic Binding - in essence, the nature of a proceedure call is not
FN-> known (predefined) until the moment of call at runtime
Dynamic binding is not really a requirement and most real (read "useful")
systems give the compile-time option to choose between dynamic and static.
Polymorphism is likewise an independent idea found also in many Functional
languages such as Hope, Lisp and I think also in FP.
As one who uses OOP everyday, I do think the list cited above does lack two
OOP features, one which is essential and the second which is very powerful
and at the same time extremely dangerous. The first is encapsulation, AKA
information hiding, which imposes strict scoping on variables and selected
functions and allows a complete change of the implementation without affecting
the remainder of the application (provided the interface is unchanged). The
second is multiple inheritance, the bane of all OOPL designers, but a very
powerful idiom when used correctly.
--
Gary Murphy uunet!mitel!sce!cognos!garym
(garym%cognos.uucp@uunet.uu.net)
(613) 738-1338 x5537 Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3
"There are many things which do not concern the process" - Joan of Arcdwp@willett.pgh.pa.us (Doug Philips) (09/22/90)
In <GARYM.90Sep21085425@cognos.uucp@uunet.uu.net>, garym@cognos.uucp@uunet.uu.net (Gary Murphy) writes: > As one who uses OOP everyday, I do think the list cited above does lack two > OOP features, one which is essential and the second which is very powerful > and at the same time extremely dangerous. The first is encapsulation, AKA > information hiding, which imposes strict scoping on variables and selected > functions and allows a complete change of the implementation without affecting > the remainder of the application (provided the interface is unchanged). The > second is multiple inheritance, the bane of all OOPL designers, but a very > powerful idiom when used correctly. I agree with you on encapsulation. I have yet to be convinced that any knows how to use Multiple Inheretance effectively, or even what it "really means." As there are at least three different styles/types of multiple inheretance(MI) it doesn't seem as if a consensus is near. I don't object on the grounds that MI is too powerful or too dangerous, but that it is an ill-defined or perhaps even ill-definable concept (that is, even more ill-defined that OOP itself). On the other hand I have yet to make a dent in the OOF/OOP bibliography Mitch posted. -Doug fFuOtRuTrHe (FORTH in the future) --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/07/90)
Category 3, Topic 46 Message 73 Sun Dec 11, 1988 K.SMITH10 (Forwarded) Well... now that OOPs is becoming quite a topic for FORTH people, does anyone have the low down on whether Kriya still exists and supports NEON? (For those unfamiliar, it was first offered in 1984 for the Mac, was created by Charles Duff of Actor fame, and is a very comprehensive OOPs/FORTH environment). I'd love to see NEON, not just OOPs partials, implemented for MSDOS. It represents quite a bit of work towards defining how FORTH can work as an OOPs environment, and would be a good model to compare/follow for new efforts. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/07/90)
Category 3, Topic 46
Message 74 Sun Dec 11, 1988
GARY-S (Forwarded)
I have serious doubts there is any official activity in Neon, but I don't
honestly know that for a fact. I do know when I talked to Charles Duff a few
years ago he was then speaking of Neon in mature terms and was just then
bringing Actor out. There were some problems that limited the strength of Neon
in the AI world, but it was an interesting mesh of Forth with Smalltalk. The
last address I have for Kriya is 505 N. Lake Shore Drive, Chicago, IL
60611...
Give that a shot and let us know what you find out.
Good Luck , Gary
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/07/90)
Category 3, Topic 46
Message 75 Fri Jul 28, 1989
GARY-S [Gary] (Forwarded)
Read article (Usenet)
/Gateways/Usenet/comp/lang/forth/oo forths
1015.3.388.1 oo forths
7/26/89 08:36 rfl@oddjob.uchicago.edu (Bob Loewenstein)
-----
Speaking of object oriented forths...NEON is still alive and
well on my Mac II. There are a few basic additions to the kernel
(like a methods stack using another 68000 address register). The
rest is high level additions to forth. The additional stack
allows the use of local and named input variables.
Multiple cfa words can also be defined . Early and late binding are
supported. Instantiation in the the dictionary or on the heap.
-----
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/07/90)
Category 3, Topic 46 Message 76 Fri Jul 28, 1989 GARY-S [Gary] (Forwarded) Read article (Usenet) /Gateways/Usenet/comp/lang/forth/oo forths 1015.3.388.2 Re: oo forths 7/27/89 10:47 kevinbe@microsoft.UUCP (Kevin Berg) ----- In article <4651@tank.uchicago.edu>, rfl@oddjob.uchicago.edu (Bob Loewenstein)> > > Speaking of object oriented forths...NEON is still alive and > well on my Mac II. There are a few basic additions to the kernel > (like a methods stack using another 68000 address register). The > rest is high level additions to forth. The additional stack > allows the use of local and named input variables. > Multiple cfa words can also be defined . Early and late binding are > supported. Instantiation in the the dictionary or on the heap. The author of Neon went on to make Actor, an Object Oriented environment for MS-Windows. Is Kriya Systems still supporting Neon? There were many bugs reported in the early versions, which turned me away. I'm interested in this if the support has been decent. It might also be interesting for you to share some of the OO implementations that you find useful, or cumbersome, via example. I'm sure many others would be interested. - k ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/07/90)
Date: 07-29-89 (17:08) Number: 1986 (Echo) To: GARY SMITH Refer#: 1983 From: SYSOP (ECFB/SHIFRIN) Read: NO Subj: OOF Status: PUBLIC MESSAGE GS>The author of Neon went on to make Actor, an Object Oriented GS>environment for MS-Windows. The truly dedicated may wish to look up Charles Duff's paper, Development of a Threaded Object-Oriented Language, in Volume 4, issue #2 of The Journal of Forth Application and Research (proceedings of the 1986 Rochester Forth Conference). Duff discusses the reasoning behind some of the Actor language development. --- * QDeLuxe 1.10 #214s :S ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/24/91)
Category 3, Topic 46
Message 91 Sun Apr 21, 1991
B.RODRIGUEZ2 [Brad] at 21:49 EDT
[ If anyone would like a copy of one/more/all of these files, please
drop me a note at one of the addresses at the end of this message.
All binary files are UUencoded. Files are then split (if necessary)
into mailer-acceptable sized pieces and then mailed to you.
In order for me to answer your request, you must:
Include the line containing the file name. (so I know what you want.)
Include your email address in the _body_ of the message. You _must_
include an address *relative to* the InterNet or well known
UseNet site.
-dwp]
From Nick Janow:
> "Re: 'Easy' way to put 'AI' in realtime embedded systems?"
Depends. If you're talking about the subset of AI known as Expert Systems, I
can answer: Yes, it's easy in Forth.
I took a course on expert systems only two years ago, and had quite a compact
and efficient package written quickly. I reported on it at the 1990 Rochester
Forth Conference, and I've promised to write it up for Embedded Systems
Programming.
The Forth code is in the GEnie library as file EXPERT90.ZIP. Damfino if it's
available FTP.
Brad Rodriguez | brad%candice@maccs.uucp (God willing)
B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
"Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic)
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwprfl@oddjob.uchicago.edu (Bob Loewenstein) (05/01/91)
Regarding the message about "NEON/Object Oriented Forth/OOF" availablity...Make sure that the version is at least 3.3.0. Also, "NEON" does not exist anymore, the public domain version currently is called "YERK". Since I am the one that placed it into the public domain with Kriya's permission, please make sure the agreement is maintained. There should be a README file with Yerk to explain this. There is an updated version that will be available on oddjob.uchicago.edu in the ~ftp/pub/Yerk directory. This version is 3.3.2 and fixes a few bugs and some cosmetic changes. 3.3.2 is not there now, but I'll make another announcement when it will be. For those that have Yerk, if you can drop me an email message or a postcard, so when upgrades become available, I can let people know. Also feel free to send in comments or bug reports...I do take care of these. Bob Loewenstein Dept. of Astronomy and Astrophysics The University of Chicago Yerkes Observatory Williams Bay, Wi 53191 414-245-5555 rfl@oddjob.uchicago.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/28/91)
Category 3, Topic 46
Message 101 Sat May 25, 1991
B.RODRIGUEZ2 [Brad] at 13:23 EDT
My favorite definition of Object-Oriented Programming:
"A paradigm focusing on data structures, providing methods for operating on
those data structures, and providing inheritance."
- Paul Snow
It's my favorite because Paul was able to write it on the back of my business
card at a Rochester conference. (Some producer -- who? -- once said that if
you couldn't write your idea on the back of his business card, you didn't have
a clear idea.)
Now, does anyone want to elaborate on Paul's definition?
- Brad
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpfish@ecst.csuchico.edu (Kevin Haddock) (05/29/91)
In article <2822.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: >Category 3, Topic 46 >Message 101 Sat May 25, 1991 >B.RODRIGUEZ2 [Brad] at 13:23 EDT > > >Now, does anyone want to elaborate on Paul's definition? > >- Brad >----- I have a few comments about the subject of Object Oriented Programming and Forth Naming/Documenting conventions. First of all few of you have mentioned some of the most usefull features of OOP (IMHO), those being 1) dynamic (late) binding and 2) virtual memory (usually included but not an "actual requirement" of OOP). Dynamic binding gives one the ability to plug and unplug different types of objects to/from each other; to not know or care what type of object is the receiver but just that it can (or can't) understand a certain type of message. I was working on an adventure game programming language written in FOOL (my own dialect of OOP: Forth Object Oriented Language) that provides a good example of this. Each player (if you were to have a multi-player environment) would be an object. One of the objects (read variables) that is a part of the player object is the location. That location object points to a room object; actually it can be considered to 'be' the room object that you are in. Each room object has another ajoining room object in each relevant compass direction (e.g. N S E W). When you move from room to room you send that object the 'go' message. For example you would say: "NORTH go". Now you never know whether to the north lies a WALL object, another ROOM object, or something altogether different like an ELECTRIC_FENCE object, all of which would affect your PLAYER object differently. The WALL object would just print the message "*CRASH* you just ran into a wall!" and not affect your location (except, maybe, requiring you to get up off the floor!) and might reduce your health or stamina. A ROOM object would change your PLAYER's LOCATION object possibly by sending it an 'at' message and the ELECTRIC_FENCE object could send the PLAYER object a 'zap' message that could initiate a reincarnation cycle! (or something to that effect). One of the nice things about dynamic binding is that you can change object types midstream. For instance you could do something like change a wall into a passage or vice versa ("gee, I would have sworn there was a wall there a couple of seconds ago"). Virtual memory makes an object oriented system kind of like a living breathing thing (be careful not to kill it!). There is no differentation between disk and RAM per se. It is kind of like a FORTH system would be with a large amount of NVRAM. The main difference being that an object system does not require you to do your own memory management like FORTH does. The address space is not linear or paged but more like a heap. Objects are dynamically created and distroyed with great rapidity. A whole science has been created over this issue. How do do it fast enough, generation scavenging, recursive garbage collection, etc... See, I think it's Sept '83 Byte for a good overview of the different aspects/challenges of the Smalltalk 80 system and VM management in an object environment. Now how this relates to FORTH coding conventions and readability. First thing I have against FORTH syntax and all the OOPS I have run across is they all have the syntax BACKWARDS! The VERB COMES FIRST!!!! Matter of fact verbs and nouns are interchangeable and have totally different meanings. For example the phrases: Verb Connect Noun Book A Ship Ship A Book Water The Fish Fish The Water The biggest problem I see with FORTH is that you have to make up so many names and concatenate all kinds of wierd 'jerry rigged' syntax around them to convey what they are. Either that or you have to resort to long-hyphenated-names and the vertical code that goes along with it. I have been working on a parser that I believe corrects that problem. It works something like this: The verb is an object who's behavior when parsed/interpreted is to put it's selector object (the token that represents the message) on the stack. Whenever a noun is interpreted it's behavior is to send itself to the verb object on top of the stack (or does the second send itself to the first, I can't remember; it's been awhile since I played with this). At the end of the processing of a method the remaining objects on the stack are sent to each other until just 'inert' objects remain as results. Those 'inert' objects are basically those that have had all their argument needs satisfied. With this type of parser/interpreter and an object oriented system, a FOOL could be very readable because you would re-use lots of little verbs, create a few short sweet nouns, and the source code would not look like some kind of reverse-polish-greek-form-of-hyphenated-pig-latin! Another quick note: In a true object oriented system the objects are created unbound and float on the stack until they are either no longer needed (90% of the cases) or are bound to a name. I haven't seen too many FORTH OOP's that do this (but then again I haven't seen too many FORTH OOPS!). fish@ecst.csuchico.edu ======================================================================= Flame all you want! We'll make more!
paulb@minster.york.ac.uk (05/29/91)
In article <2822.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: >My favorite definition of Object-Oriented Programming: > >"A paradigm focusing on data structures, providing methods for operating on >those data structures, and providing inheritance." > - Paul Snow > >It's my favorite because Paul was able to write it on the back of my business >card at a Rochester conference. (Some producer -- who? -- once said that if >you couldn't write your idea on the back of his business card, you didn't have >a clear idea.) > >Now, does anyone want to elaborate on Paul's definition? > >- Brad If you're into short definitions, how about this one (I'm not sure of the original source - I heard it from a colleague). "An object is a record of first class procedures" I think it sums up what's going on nicely, although it isn't a definition I'd give to a novice! ;-) Paul. +--------------------------+-----------------------------------------------+ |Paul Butcher | JANET: paulb@uk.ac.york.minster | |Dept. of Computer Science | EARN: paulb@minster.york.ac.uk | |University of York | UUNET: ..!uunet!mcsun!ukc!minster!paulb | |York YO1 5DD ENGLAND | ARPA: paulb%york.minster@nsfnet-relay.ac.uk | |Tel: (0904) 432760 | Alternative address: | | (+44 904) 432760 | PRAB1@uk.ac.york | +--------------------------+-----------------------------------------------+
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/08/91)
Category 3, Topic 46 Message 109 Fri Jun 07, 1991 G.LEFAVE [Gene] at 17:08 CDT To: dwp@willett.pgh.pa.us (Doug Philips) Subject: Re: OOF Regarding types: I've implemented Dick Pountains wordst in polyFORTH, and used it for a couple of months. The implementation esentially maintains a separate vocabularly for each class. Referencing the name of an object, at either compile time or run time, gives you access to the wordset. How this differs from a "type" escapes me. I regularly use database objects that have numeric, string, dates, time, dollars and key types. All of which share identically named methods. So far I have never needed to know the "type" of an object as it knows its own type. Certainly, if one wanted to, a method named "type" could be added which returned the name of an object type. It seems to me that this runs counter to the object philosophy, namely that a program shouldn't know about the implementation details of the objects. Perhaps you could describe how a "type" is different from the list of methods that are provided by a class. Gene ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/10/91)
Category 3, Topic 46 Message 110 Sat Jun 08, 1991 B.RODRIGUEZ2 [Brad] at 14:17 EDT Re. Boyd Hays' list of questions: 4) I understand GRAY.4TH is a parser somewhat akin to Yacc. I have a copy, but haven't looked at it yet. You might ask Mitch Bradley (Mitch.Bradley@Eng.Sun.com) for more info. Also, I've done a few really simplistic parsers, one of which was published recently in the sigForth newsletter (vol.2 no.2). 5) Seems like a good list. I also think highly of Brodie's "Thinking Forth"...if you can find a copy (it's out of print). - Brad Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
dwp@willett.pgh.pa.us (Doug Philips) (06/10/91)
In article <2861.UUL1.3#5129@willett.pgh.pa.us>, G.LEFAVE [Gene] writes: > I've implemented Dick Pountains wordst in polyFORTH, and used it for a couple > of months. The implementation esentially maintains a separate vocabularly for > each class. Referencing the name of an object, at either compile time or run > time, gives you access to the wordset. How this differs from a "type" escapes > me. I regularly use database objects that have numeric, string, dates, time, > dollars and key types. All of which share identically named methods. So far > I have never needed to know the "type" of an object as it knows its own type. > Certainly, if one wanted to, a method named "type" could be added which > returned the name of an object type. It seems to me that this runs counter to > the object philosophy, namely that a program shouldn't know about the > implementation details of the objects. > > Perhaps you could describe how a "type" is different from the list of methods > that are provided by a class. There is no difference. Forth is not traditionally a typed system. OOPs are. Not that the programmer/user has to be aware of the types, bu the system itself does. I'm not a long time Forth user, but every NON-OOF Forth I've seen did nothing to tell you if you should use + or D+ or F+ ... the programmer has/had to make that decision. In OOPs, you just use + and the system figures it out for you. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/19/91)
Category 3, Topic 46 Message 116 Tue Jun 18, 1991 G.LEFAVE [Gene] at 06:52 CDT Brad, Re: your parser. I converted it to polyFORTH, and amazed my coworkers with it. My version outputs into a block that is then loaded. A wonderful little program. Gene ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp