Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: ...and zen there were objects.
Message-ID: <1682.UUL1.3#5129@willett.pgh.pa.us>
Date: 7 Sep 90 01:17:10 GMT
References: <1990Aug30.193356.26274@idacom.uucp>
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 64

In <1990Aug30.193356.26274@idacom.uucp>, rob@idacom.uucp (Rob Chapman) writes:

>  One may make this interesting if we allow active objects and active methods.
>  These objects and methods may do different things depending on the context.
>  ie.
>   	File-Menu
> 
>  The object File-Menu could activate itself when executed and display an
>  apropriate popup menu.  If it was already active, it would deativate
>  itself.

I think that that may be an interesting variant on object-active OOF, but I
don't see how it avoids having to name every object, which is my primary
objection to object-active OOF.  This is a separate issue from the details
you go into below, however.

>     #up 1 0 infinite#  ' KeyCounter INITIALIZE  ( count keystrokes forever )
>    or
>     ' COUNT-UP  ' KeyCounter BIND  1 0 infinite#  ' KeyCounter INITIALIZE

I much prefer the latter scheme, with the exception for making the object
_name_ active.  (implied by needing to quote) and having message names
last.  (What you are doing is good, but I disagree with how you say it).

>  Getting back to your views on syntax, this could be achieved by binding
>  different actions to the objects and methods.

I was at first intrigued by this, but it seems to violate the encapsulation
ideas of OOP.  Objects should have their actions "bound" by the code and
data structures that define the object.  I'm not sure what it means to have
a "rebind" message, but it doesn't seem right to call it OOP.

>  The key issue here, is Forth is a meta-language (amongst other things).  It
>  is used to create languages to abstract solutions into the computer domain.
>  Once one understands the problem, the solution is intuitive (assuming the
>  converse: if a solution is not known, the problem is not understood).
>  Forth allows quick protyping of ones initial understandings of a problem
>  which allow progression towards a solution.

I agree with all of that.

>  Addressing your discussion with this perspective, Forth is the appropriate
>  language to prototype oo syntax.  By adopting an extensible set of oo
>  tools, we can adapt the syntax to different situations.  If ANS Forth had
>  an oo wordset, it could probably consist of the word BIND !  

I think your BIND could be used to implement an OOF, but I don't think it
_is_ an OOF.

>  Hysterically speaking this in not unlike the defur stuff with a little more
>  edge.

Exactly.  As Bouma has pointed out, DEFER ( indirect function call ) is
often how OOF is implemented, but implementation isn't interface.  (i.e.
one uses stack objects in the same manner regardless of whether they are
implemented as arrays or linked lists or ....  )

-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]