larry@hpfcrj.HP.COM (Larry Fenske) (07/17/87)
Yup, me too. Larry Fenske
karl@haddock.ISC.COM (Karl Heuer) (07/18/87)
In article <sUzP8Vy00Us=wNM0-x@andrew.cmu.edu> lord+@andrew.cmu.edu (Tom Lord) writes: >3) Does there exist an object oriented forth or forth extension? Last time I visited Caltech I was shown some information about a language called FITH. (The name is evidently formed by dropping a letter from the middle of "fifth", analogous to the transformation "fourth" -> "forth"; I must mention that I consider this name an abomination.) Sorry, I didn't see enough of the language itself to make any helpful comments. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint "FORTH is just like LISP, only written backwards, and without the parens."
darryl@ism780c.UUCP (Darryl Richman) (07/18/87)
In article <755@haddock.ISC.COM> karl@haddock.ISC.COM (Karl Heuer) writes: <In article <sUzP8Vy00Us=wNM0-x@andrew.cmu.edu> lord+@andrew.cmu.edu (Tom Lord) writes: <>3) Does there exist an object oriented forth or forth extension? < <Last time I visited Caltech I was shown some information about a language <called FITH. (The name is evidently formed by dropping a letter from the <middle of "fifth", analogous to the transformation "fourth" -> "forth"; I must <mention that I consider this name an abomination.) Sorry, I didn't see enough <of the language itself to make any helpful comments. On the Macintosh there is a language called Neon that might be described as smalltalk on top of forth. A strange and interesting combination, with pretty good performance to boot. --Darryl Richman, INTERACTIVE Systems Corp. ...!cca!ima\ >-!ism780c!darryl ...!sdcrdcf/ The views expressed above are my opinions only.
clark@polecat.caltech.edu (Clark Brooks) (07/21/87)
I work on the FITH project at Caltech. It is very similar to FORTH in
syntax (identical), and in that it is a TIL. The flavor, however is strongly
influenced by Smalltalk. Named local variables and arguments help avoid the
impenetrability of rudimentary FORTH's. Unfortunately, it is big. It is happy
in about 2 Meg. And, it is relatively slow. We compare it to Smalltalk to
make it seem fast. I find it a very pleasurable language to program in.
It is, on the other hand, fast enough to do real work in, and it combines the
advantages of FORTH and Smalltalk for whipping up projects.
We are working on documentation now. With luck you will kear more in
finite time.
Take whatever action seems appropriate at the time. -- E**2rap@dana.UUCP (Rob Peck) (07/21/87)
> In article <sUzP8Vy00Us=wNM0-x@andrew.cmu.edu> lord+@andrew.cmu.edu (Tom Lord) writes: > >3) Does there exist an object oriented forth or forth extension? JFORTH, for the Amiga, has a package of object-oriented extensions. I don't know if they are supplied as source code or not but I did find the documentation to be very interesting. Check out a local Amiga dealer, they might be able to let you look at the package. Rob Peck ...ihnp4!hplabs!dana!rap
carroll@udel.edu (Mark Carroll <MC>) (09/01/90)
A lot of discussion (and flamage) has wandered its way through this newsgroup recently. Unfortunately, the disccusion seems to have digressed so far from the important issues of the subject that I'm going to try starting a separate chain. To me, there are a few key issues to consider in the design of an object-oriented extension to Forth. 1> What exactly do we mean by object-orientation? 2> What form of object-orientation is best-suited to Forth? 3> What syntax is most natural for this form? To me, object-orientation is a model of computation where the objects are active and the operations passive. This doesn't sound like much right now, but I think it's a very important thing to remember when it comes time to design a syntax. What form of object-orientation is most well-suited to Forth? This is a much more difficult question. It helps to consider the models that are available. In my opinion, there are four primary models of object-orientation: [1] Loosely-typed class (Smalltalk), [2] Strongly typed class (C++, Eiffel), [3] Prototyped (Self), and [4] Law Governed Systems (Darwin). I think that we can immediately eliminate [2] (Forth has never had strong declared typing, so it would be unnatural to add it for OO), and [4] (Forth has always been very minimal - a Law Enforcement system in the message pass mechanism would be very unforthlike). This leaves us with [1] and [3]. Which of these is most well-suited to Forth? I tend to believe that it would be three. Forth is naturally a very open and unrestricted language. It tends to lean towards the more open and unrestricted style. The prototype model of object-orientation is more open, and makes fewer assumptions about the nature of the object heirarchy. Now, what kind of syntax is most well-suited for this model? Because of the nature of object-orientation, I would lean very strongly away from active method names. I think that it would be a very major mistake to use the syntax: arg1 arg2 object message Because this fogs the nature of object-orientation. It would be more natural to use: arg1 arg2 message object With the object active. But I also lean away from that. I agree with the arguments of Doug Philips (?) in favor of an explicit send: arg1 arg2 message object SEND The explicit send does still make it obvious that the object is the active entity in the computation; it also makes it obvious that a message pass is happening, it makes the expression easier to scan, and it makes a cascade more intuitive. Now, the important question is what kind of syntax to use for actual object creation. This, I'm very uncertain of. I would like to see what some other folks think about an appropritae syntax before I make any decision of what I like best. Go ahead, rip me apart. <MC> -- |Mark Craig Carroll: <MC> |"We the people want it straight for a change; |Soon-to-be Grad 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
peterc@gkcl.ists.ca (Peter Camilleri) (09/01/90)
In article <29113@nigel.ee.udel.edu> carroll@udel.edu (Mark C. Carroll <MC>) writes: > > >1> What exactly do we mean by object-orientation? >2> What form of object-orientation is best-suited to Forth? >3> What syntax is most natural for this form? > >To me, object-orientation is a model of computation where the objects >are active and the operations passive. This doesn't sound like much >right now, but I think it's a very important thing to remember when it >comes time to design a syntax. > To me, an object oriented system must exhibit the following properties: late binding polymorphism type checking (if any) at RUN TIME! the encapsulation of code and data into things called "OBJECTS" the hiding of private information contained within an "OBJECT" inheretance of object class behaviour >What form of object-orientation is most well-suited to Forth? This is >a much more difficult question. It helps to consider the models that >are available. In my opinion, there are four primary models of >object-orientation: [1] Loosely-typed class (Smalltalk), [2] Strongly >typed class (C++, Eiffel), [3] Prototyped (Self), and [4] Law Governed >Systems (Darwin). > >I think that we can immediately eliminate [2] (Forth has never had >strong declared typing, so it would be unnatural to add it for OO), >and [4] (Forth has always been very minimal - a Law Enforcement system >in the message pass mechanism would be very unforthlike). > I am familiar with [1] and [2] by direct experience. Could you elaborate on [3] and [4] a bit? I would favour [1] because of its simplicity and effectiveness in problem solving. It woukd be a good idea to avoid the rabid complexity of c++ with its multiple inheritance, multi-object tree and trying to avoid the issue that classes themselves should be treated as first class objects. (I have used both Smalltalk and C++ extensively, can you guess which I prefer? :-) [discussion of syntax deleted, I tend to agree overall.] >Now, the important question is what kind of syntax to use for actual >object creation. This, I'm very uncertain of. I would like to see what >some other folks think about an appropritae syntax before I make any >decision of what I like best. > In the same manner as Smalltalk, I feel that classes should be objects. They would be responsable for creating new objects, hold class wide data, and performing other "objectless" processing. The classes would be instances of the class MetaClass, which would be pre-existing. In the spirit of FORTH, MetaClass could be subclassed to allow new classes to be created in different ways. (Not too unlike a defining defining word) >Go ahead, rip me apart. > The above probably applies to me more than to you. Apology #1 - I flunked grade six spelling, so no spelling flames please! Peter Camilleri peterc@stpl.UUCP 1543 Marshcourt Drive uunet!mnetor!yunexus!stpl!peterc Pickering, Ont L1V-6C8
carroll@udel.edu (Mark Carroll <MC>) (09/02/90)
In article <12070@ists.ists.ca> peterc@gkcl.UUCP (Peter Camilleri) writes: ]In article <29113@nigel.ee.udel.edu> carroll@udel.edu (Mark C. Carroll <MC>) writes: ]] ]] ]]1> What exactly do we mean by object-orientation? ]To me, an object oriented system must exhibit the following properties: ] late binding ] polymorphism ] type checking (if any) at RUN TIME! ] the encapsulation of code and data into things called "OBJECTS" ] the hiding of private information contained within an "OBJECT" ] inheretance of object class behaviour ] We're basically saying the same thing. The only difference is that I think that it's very important to lay the "theoretical" groundwork first. Late binding, polymorphism, etc., are all actual features that together can be used to create an object-oriented system. I would prefer to decide what an object-oriented system should be, and then decide what features I need to implement it. 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. ]]What form of object-orientation is most well-suited to Forth? This is ]]a much more difficult question. It helps to consider the models that ]]are available. In my opinion, there are four primary models of ]]object-orientation: [1] Loosely-typed class (Smalltalk), [2] Strongly ]]typed class (C++, Eiffel), [3] Prototyped (Self), and [4] Law Governed ]]Systems (Darwin). ]] ]]I think that we can immediately eliminate [2] (Forth has never had ]]strong declared typing, so it would be unnatural to add it for OO), ]]and [4] (Forth has always been very minimal - a Law Enforcement system ]]in the message pass mechanism would be very unforthlike). ]] ]I am familiar with [1] and [2] by direct experience. Could you elaborate ]on [3] and [4] a bit? Sure. [3] Prototyped Object Orientation: Prototyping represents a different regime of object-orientation that the traditional class based system. The idea of prototyped languages is: we want to create a system where everything is an object. 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. [4] Law Governed Systems LGS's are also basically classless object-oriented systems. They start out similar to a system of prototypes, only they don't include any method of delegation. In the initial system, any object can be passed any message. Then, by imposing laws, the programmer can restrict or alter the passing of messages by imposing laws on the system. Once laws have been imposed, every message pass is passed through a governor. The governor examines the message, its recipient, and its sender, and decides whether to pass the message, alter the message, redirect the message, or block the message. With this system, you can impose a regime of delegation, inheritance, or anything else that you can imagine. LGSs are largely experimental, but a gentlman at Rutgers has implemented a complete one with a governor written in Prolog. (And I've written a very Small LGS around a prototype package for Scheme.) They're extremely nice, but very slow... ]I would favour [1] because of its simplicity and ]effectiveness in problem solving. It woukd be a good idea to avoid the ]rabid complexity of c++ with its multiple inheritance, multi-object tree ]and trying to avoid the issue that classes themselves should be treated as ]first class objects. (I have used both Smalltalk and C++ extensively, can ]you guess which I prefer? :-) ] I've also used both, and I very greatly prefer Smalltalk. But I think that implementing a system like either Smalltalk or C++ would be a very big mistake for Forth. If we were to lean in the direction of Classes, I think that a weak class system where classes weren't objects would be best. But I still think that the best solution in Forth is prototyping. It just seems to be the most natural idea for Forth. ][discussion of syntax deleted, I tend to agree overall.] ] ]]Now, the important question is what kind of syntax to use for actual ]]object creation. This, I'm very uncertain of. I would like to see what ]]some other folks think about an appropritae syntax before I make any ]]decision of what I like best. ]] ]In the same manner as Smalltalk, I feel that classes should be objects. ]They would be responsable for creating new objects, hold class wide data, ]and performing other "objectless" processing. The classes would be ]instances of the class MetaClass, which would be pre-existing. In the ]spirit of FORTH, MetaClass could be subclassed to allow new classes to ]be created in different ways. (Not too unlike a defining defining word) ] Actually, I really like this idea. 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. ]Peter Camilleri peterc@stpl.UUCP <MC> -- | Mark Craig Carroll: <MC> |"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
dwp@willett.pgh.pa.us (Doug Philips) (09/07/90)
In <29113@nigel.ee.udel.edu>, carroll@udel.edu (Mark Carroll <MC>) writes: First, I want to say that I agree whole heartedly with what you say. That doesn't mean that I think all OOFs to date have been written by dolts, idiots or stupid people. > But I also lean away from that (object-name-active OOFs). I agree with > the arguments of Doug Philips (?) in favor of an explicit send: > arg1 arg2 message object SEND > > The explicit send does still make it obvious that the object is the > active entity in the computation; it also makes it obvious that a > message pass is happening, it makes the expression easier to scan, and > it makes a cascade more intuitive. And it makes anonymous objects possible. The ubiquitous List of graphical objects used in most introductory texts/articles is the best example. > Now, the important question is what kind of syntax to use for actual > object creation. This, I'm very uncertain of. I would like to see what > some other folks think about an appropritae syntax before I make any > decision of what I like best. I take it by your rejection of the SmallTalk model you are against having classes be objects? (which necessitates meta-classes. See the SmallTalk books for how they handled that). I'm not sure what Self is. Where can I find out more about it? -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]
dwp@willett.pgh.pa.us (Doug Philips) (09/07/90)
In <12070@ists.ists.ca>, peterc@gkcl.ists.ca (Peter Camilleri) writes: > In the same manner as Smalltalk, I feel that classes should be objects. > They would be responsable for creating new objects, hold class wide data, > and performing other "objectless" processing. The classes would be > instances of the class MetaClass, which would be pre-existing. In the > spirit of FORTH, MetaClass could be subclassed to allow new classes to > be created in different ways. (Not too unlike a defining defining word) Also allows for POOL variables, but how useful that feature is, I'm not sure. The biggest win for having classes as objects is that one can then create new objects by sending messages AND customize those messages to suit the class of the object being created (i.e. all object creation messages do not have to be the same). -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]
dwp@willett.pgh.pa.us (Doug Philips) (09/07/90)
In <29211@nigel.ee.udel.edu>, carroll@udel.edu (Mark Carroll <MC>) 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]
carroll@udel.edu (Mark Carroll <MC>) (09/07/90)
In article <1683.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: >In <29113@nigel.ee.udel.edu>, carroll@udel.edu (Mark Carroll <MC>) writes: > >> Now, the important question is what kind of syntax to use for actual >> object creation. This, I'm very uncertain of. I would like to see what >> some other folks think about an appropritae syntax before I make any >> decision of what I like best. > >I take it by your rejection of the SmallTalk model you are against having >classes be objects? (which necessitates meta-classes. See the SmallTalk >books for how they handled that). I'm not sure what Self is. Where can >I find out more about it? > In general, I'm not opposed to the class-as-object model, but for a Forth system, it just doesn't seem appropriate. If you're trying to build a large-scale pure object-oriented system, classes-as-objects make very good sense. But it seems to me that for Forth, we should be looking for the smallest, most flexible, least restrictive model. The prototype model can be implemented more simply, with less code than class-as-object. If you want more information on Self, the self project at Stanford has published a number of papers. The entire group of papers is actually available as a massive postscript file, whose exact location I can't quite remember... I'll send it to you as soon as I remember. The papers have been published in proceedings from several sigplans. The best starting point is probably "Self: The Power of Simplicity", which is in the Sigplan proceedings of either 1986 or 1987. <MC> -- | Mark Craig Carroll: <MC> |"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
carroll@udel.edu (Mark Carroll <MC>) (09/07/90)
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 <MC>) 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 ) <MC> -- | Mark Craig Carroll: <MC> |"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
dwpst@unix.cis.pitt.edu (Douglas W Philips) (09/08/90)
In article <29762@nigel.ee.udel.edu> carroll@udel.edu (Mark Carroll <MC>) writes: > >In general, I'm not opposed to the class-as-object model, but for a >Forth system, it just doesn't seem appropriate. If you're trying to build >a large-scale pure object-oriented system, classes-as-objects make very >good sense. But it seems to me that for Forth, we should be looking for the >smallest, most flexible, least restrictive model. The prototype model >can be implemented more simply, with less code than class-as-object. There is definitely a lot of machinery (or a non-trivial amount) to get the full class-as-object model working. I wonder just how much Forth code it would be though. >quite remember... I'll send it to you as soon as I remember. The >papers have been published in proceedings from several sigplans. The >best starting point is probably "Self: The Power of Simplicity", which >is in the Sigplan proceedings of either 1986 or 1987. I hope you'll post it so that other interested parties can know too. -Doug --- Preferred: dwp@willett.pgh.pa.us Acceptable: uunet!willett!dwp
dwpst@unix.cis.pitt.edu (Douglas W Philips) (09/08/90)
In article <29766@nigel.ee.udel.edu> carroll@udel.edu (Mark Carroll <MC>) writes: >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. > [ Description elided... -dwp] >That's the ultra-short description of a delegated model. Now, on to >the way that you generate a group of similar objects: That sounds good, conceptually simple and powerful. [ Description elided... -dwp] >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 think I followed all that. When you speak about a refined copy method: is that different from having a copy method that asks the copy-ees superobject(s) to copy themselves and then makes those copies the copy-er's object's superobjects? Why wouldn't that be the generic default copy method, or is it? Maybe I should wait until I've learned more about Self from reading the on-line materials. >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. Two points: 1) I think the SmallTalk class/meta-class scheme is very clever and for what it does, simple. This isn't the place to debate it though. 2) How do we go about finding an OOP for Forth? Do we examine existing OOP paradisgms and apply a Forth filter to them? Do we start with Forth and try to design an OOP from that direction? -Doug --- Preferred: dwp@willett.pgh.pa.us, acceptable: uunet!willett!dwp