Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dwpst
From: dwpst@unix.cis.pitt.edu (Douglas W Philips)
Newsgroups: comp.lang.forth
Subject: Re: Object-oriented Forth
Message-ID: <36077@unix.cis.pitt.edu>
Date: 7 Sep 90 21:49:20 GMT
References: <29211@nigel.ee.udel.edu> <1685.UUL1.3#5129@willett.pgh.pa.us> <29766@nigel.ee.udel.edu>
Reply-To: dwpst@unix.cis.pitt.edu (Douglas W Philips)
Organization: Disassociated users association.
Lines: 46

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