Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!carroll From: carroll@udel.edu (Mark Carroll ) Newsgroups: comp.lang.forth Subject: Re: Object-oriented Forth Message-ID: <29766@nigel.ee.udel.edu> Date: 7 Sep 90 14:42:20 GMT References: <29211@nigel.ee.udel.edu> <1685.UUL1.3#5129@willett.pgh.pa.us> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 91 Nntp-Posting-Host: dewey.udel.edu In article <1685.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: >In <29211@nigel.ee.udel.edu>, carroll@udel.edu (Mark Carroll ) writes: > >> [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? > OK, I guess I should explain the idea of prototyping, and show a quick correspondance. I'll talk strictly in terms of the model of Self, but any other prototyped language is similar. In Self, an object is a collection of Slots. These slots can either hold values, or methods. A slot is accessed via a message. With this setup, a variable holding slot becomes indistinguishable from a method holding slot - if you send the message "x" to an object "o", then "o" will return some value. You don't know whether the value came from a computation, or was just held in the "x" slot. Each object has a set of distinguished slots, called parent slots. The parents slots contain objects which messages can be delegated to. So, given object o, and parent object p; when o receives a message that it doesn't recognize, the message is sent to p. However, (just to complicate things a bit), if the method in p sends any other messages, the receiver of those messages is o, not p. That's the ultra-short description of a delegated model. Now, on to the way that you generate a group of similar objects: Given a parentless class C, which holds methods [a,b,c], and variables [d,e,f]. Create two objects: C_Proto, and C_Traits. In C_Traits, place methods identical to [a,b,c]. In C_Proto, put variables [d,e,f], and their access methods. Now, have C_Proto delegate to C_Traits. Create a new object C_Class, which has two slots: Proto and Traits, and a method new, which creates an exact copy of Proto. C_Class is the exact equivalent of C. Now, given a class C with parent class D; create the equivalent prototyped model for D. Now, for C, create the traits object C_Traits containing the methods from C, and the proto object C_Proto containing the variables from C. Have C_Proto delegate to D_Proto and D_Traits. Create a refined copy method for C_proto which also creates a copy of the superobject. Now create C_Class exactly as before, and C_Class is an exact equivalent of C. >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. > The solution is natural for a class-as-object system; however, I still don't like the meta-regress. The metaclass object is rather enigmatic, because it's a rather "impure" object, being its own superclass. Metaclasses don't quite behave like other objects in the system, but they pretend to be just like other objects. I just don't think that the kind of system that they create is appropriate for Forth. For Smalltalk, it's definitely a good thing; but not for Forth. > >-Doug >Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) -- | Mark Craig Carroll: |"We the people want it straight for a change; | CIS Graduate Student at | cos we the people are getting tired of your games; | University of Delaware | If you insult us with cheap propaganda; | carroll@udel.edu | We'll elect a precedent to a state of mind" -Fish