Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!jarthur!petunia!csuchico.edu!fish From: fish@ecst.csuchico.edu (Kevin Haddock) Newsgroups: comp.lang.forth Subject: Re: NEON/Object Oriented Forth/OOF Message-ID: <1991May28.203116.23910@ecst.csuchico.edu> Date: 28 May 91 20:31:16 GMT References: <2822.UUL1.3#5129@willett.pgh.pa.us> Sender: news@ecst.csuchico.edu (USENET) Organization: California State University, Chico Lines: 109 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!