Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!BRFAPESP.BITNET!UNBCIC From: UNBCIC@BRFAPESP.BITNET Newsgroups: comp.lang.forth Subject: OOF Message-ID: <9106020320.AA27050@ucbvax.Berkeley.EDU> Date: 29 May 91 20:32:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV Distribution: world Organization: The Internet Lines: 77 => Date: Wed, 29 May 91 15:00:02 GMT => From: Doug Philips => => Subject: Object Oriented Forth.. => I don't think you've made the case for having to have long hyphenated => names. And reverse polish is the nature of Forth. ^^^^^^^^^^^^^^^ It is, in fact, one of it's strengths. It makes things simple. => > 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!). Good point. But that's not part of the OOS, it's just an way of handling things. I *really* prefer named objects, i.e., Objects would return already known objects, instead of creating new ones. => The question is really one of what OOP oughta look like in Forth. => => OOP requires knowing the types of things. => Forth is traditionally untyped. Knowing types? No. OOP requires that only methods defined for an object have access to it's data fields. I handle this with vocabularies. A class is a vocabulary. It's methods data fields are defined inside this class, so only this methods can have access to the fields (Of course one could get-order, but it doesn't matter). The fields are allocated with a special word, like ARRAY. No types. What then happens? MESSAGE -- Creates a word that gets an object from stack and search for himself in this object, executing then the associated CFA. The object have it's value saved. OBJECT: -- Creates a vocabulary, initialize some variables, and creates a word with these values. A VALUE will keep the address of this word so that the words bellow can change the values. METHOD: -- Get the following word (an already defined MESSAGE), and save the ID of the message and the CFA (returned by START:) at HERE. (Changes OBJECT or CLASS). Then it START:s. When the object is executed, it leaves an value on the stack. When MESSAGE is executed, it gets this value, saves it, and search for METHOD in a list somewhere in Object. When Method is finally executed, all the references to the object's data (just offsets) is added to the start of the data area of the Object (whose value it's known). No types. It's just a complex DEFERred word. => OOP usually requires automatic memory management. => Forth is traditionally very flexible in letting you roll => your own memory management. Automatic doesn't mean you can roll your owm memory management. In fact, if you don't want one of the kinds I offer to you (static, dynamic and virtual), you can do your own without changing anything else. => Therefore adding OOP to Forth is _not_ just adding a few new defining => words (object, class, message, whatever), but requires an integrated Right. => effort to achieve a typed _and_ memory managed system onto which an OOP => can be added. That is, if you want to go the whole nine yards and have Wrong. The memory management system can be yours. And you don't need types. Inheritance, hidden data fields and everything else can be obtained by just another level between you and the machine. ALLOT won't just ALLOT, it will keep the size and the offset of this. Things like that. Maybe I can post some words (< 3Kb of source with documentation) that enables you to use objects, although without Inheritance. => -Doug => --- => Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET