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: <9106070453.AA08025@ucbvax.Berkeley.EDU> Date: 6 Jun 91 17:38:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV Distribution: world Organization: The Internet Lines: 79 => Date: Tue, 4 Jun 91 17:15:03 GMT => From: Doug Philips => => Subject: RE: OOF => +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. => => Well, not necessarily. Naming objects is not exactly the same as already => known objects. Must the objects in an array have names? Must the objects => in a list have names? If you have an OOF with "active" object names, then => those have to be special cases... Very Inelegant. An array of objects. The array have name, right? That's ok. The whole problem is that, in Smalltalk for example, when an object do something (2+2, for example), it generates an object, allocating memory, creating links and lot's of stuff. I think that Forth will *NEVER* be completly OO. So, the result of operations, such as 2+2, will not be an object. Smalltalk will create an object 4, wich will be destroyed later, when it's not needed anymore. That's what I call a nameless object. => +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, b ut => +it doesn't matter). The fields are allocated with a special word, like ARRAY . => +No types. What then happens? => [Example elided... -DWP] => + No types. It's just a complex DEFERred word . => => Sigh. I should have KNOWN that would cause problems. OOP requires objects => to have a type. Forth is traditionally untyped. The stack is just a stack => of numbers. Forth traditionally requires the programmer to know which of => + D+ F+ .. to use. In order to take that requirement away from the programme r, => the objects on the stack must have a type associated with them (how that => association is achieved is an implementation detail). TYPE, from what I've learned, it's the description of a data structure. A typed language treats diferent types in diferent ways. A strongly typed language assures an exact mach of types. But, in OO, you *HIDE* the structure. What you put in the stack is an address to a record with a list of methods and data space. (Well, it's usually more complex, but can be reduced to that). I just can't see a type here! There is NO description of the data structure, just the CFAs of methods that handle the object. There is no analysis, by the compiler, or run-time, of ANYTHING. There is a search in the list of methods, and the execution of a CFA. If you consider the list of methods a kind of type, ok. But I consider this an object. => I seem to have hit a magic button with my use of the word 'type'. If you don 't => have types you can't tell the class of an object, and therefore cannot => do method lookup for that object. As for memory management... I suppose the => key issue not some particular implementation, but the interface used by the => OOP system. +-.... Looks like what you don't like is having overloaded operators... I think of overloaded messages as a vectored word. For me, it's like writing KEY and knowing that in another place in my program I decided what KEY means. For example: SERIAL KEY (object message) and KEYBOARD KEY. Maybe SERIAL is an object with a pointer to the KEY that will be used. Maybe SERIAL is a word that assigns a new CFA to KEY. One more thing, remember that an object don't need to have data space. How can you call something that DON'T HAVE any datum a typed thing? => +Daniel C. Sobral => +UNBCIC@BRFAPESP.BITNET => => -Doug (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET