Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.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: Object oriented programming extension for forth.
Message-ID: <1568.UUL1.3#5129@willett.pgh.pa.us>
Date: 23 Aug 90 00:13:03 GMT
References: <1990Aug21.170600.26447@ida.liu.se>
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 56

In <1990Aug21.170600.26447@ida.liu.se>, mip@IDA.LiU.SE (Mikael Patel) writes:
> Some of the latest postings have suggested using a prefix
> message-passing operator.

??? PREFIX message passing operator?  I haven't seen that go by, could
you elaborate?

>  10 10 Point instance aPoint 
> ...
> -10 10 aPoint moveTo
> 
> The style follows "normal" forth and there is, in principle, 
> no difference between a colon definition and a message on
> the "surface".

I think that belies an object orientation, but I've said that several
times already.  If you are going to put OOP on top of Forth, then how
much will OOP bend to fit and will it still be OOP when you are done.
And how much will you bend Forth to meet it "halfway"?  I think that
perhaps this is an unstated "obvious" question which we are answering
differently.

> I believe that we should look for the definition of a common
> object oriented extension for forth and then work on the real 
> problem: A library with reusable classes. 

I think that that is a good idea if we can reasonably agree on the
OOF extensions to build from.  I would hope that the low level
implementation would not be allowed to overly (if at all) influence
the OOP extensions.  I think that that would be a good test of Forth's
so called extensibility.  Personally I think it can be done.

>      : canUnderstand ( message class -- bool)
>           Returns "true" if the class can understand the  message
>           (there exists a method) else "false".
> 
>      forward doesNotUnderstand ( message object -- )
>           Forward declared error message. Sent to an object  when
>           the  message  lookup  mechanism  fails.  May be used to
>           implement "proxy" objects.
> 
> 
>      : send ( object message class -- object)
>           Primitive message sending function. Used by the  normal
>           message-passing,  "message",  mechanism  to  locate and
>           apply a method.

I don't quite understand why the ordering of message and object or class
on the stack isn't consistent.  Perhaps I should hold my questions until
the implementation is released.

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