Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp From: dwp@willett.pgh.pa.us (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: Object-oriented Forth Message-ID: <1685.UUL1.3#5129@willett.pgh.pa.us> Date: 7 Sep 90 01:43:39 GMT References: <29211@nigel.ee.udel.edu> Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 63 In <29211@nigel.ee.udel.edu>, carroll@udel.edu (Mark Carroll ) writes: > In an object-oriented system, we want to be manipulating objects through > messsages sent to the objects. This requires some sort of late binding. > The use of late binding of messages to routines obviously provides > polymorphism. We also want tight encapsulation of objects. Type-checking > has nothing to do with OO - we can include it or not as we choose. And > we also need some form of behavior inheritance. But not necessarily CLASS > inheritance. Agreed, so far. > [3] Prototyped Object Orientation: > > Smalltalk attempted this, but came accross problems with metaclass > regress, etc. Rather than deal with this, just simple say that > EVERYTHING is an object, and eliminate the entire idea of classes. An > object is a collection of dataslots, and methods. When you receive a message > that you don't understand, instead of looking for it in your superclass, > delegate it to your superobject. (In other words, rather than inheriting > from an abstract entity like a class, just directly delegate messages to > some other object.) > > In terms of modeling, this is very much like classes - there is a simple > mechanical translation from classes to prototypes. It is much simpler > though, because it eliminates the enigmatic class object. Ok, I'm having difficulty understanding the distinction between a superobject and a superclass. Without classes, how do you create bunches of objects that all have the same behaviour? (i.e. do all your rectangles just happen to behave the same way, or is there no concept of "rectangle" at all?) I thought delegation was more along the lines of, to use an example: sending a "car" the message "start" meant that the "car" would delegate (forward) the start message to its "engine" component. Is this a different kind of delegation than you are talking about? I don't think the SmallTalk class/meta-class system is all that enigmatic. It isn't trivial to understand either, but I have always attributed that to the problem space being hard to understand (once you really dig into it) rather than their solution being unnecessarily opaque. > [4] Law Governed Systems It sounds from your description as if LGS is a tool one might use to build an OOP system, but I'm not sure I'd call a LGS OOP. It reminds me of some of the Common Lisp / Flavours stuff with daemons, but I don't remember the details enough to be positive of the similarity. > Actually, I really like this idea [SmallTalk description elided -dwp]. I'm > not too sure of how good an idea classes as objects are, but I does seem to > be terribly Forthish to allow creation of new metaclasses. If we must have > classes, I really like this idea. Likewise. Hopefully we'll soon have a good bibliography of existing Forth systems to examine? -Doug -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]