Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!liuida!mip
From: mip@IDA.LiU.SE (Mikael Patel)
Newsgroups: comp.lang.forth
Subject: Re: Object oriented programming extension for forth.
Message-ID: <1990Aug23.160723.437@ida.liu.se>
Date: 23 Aug 90 16:07:23 GMT
References: <1990Aug21.170600.26447@ida.liu.se> <1568.UUL1.3#5129@willett.pgh.pa.us>
Sender: news@ida.liu.se (News Subsystem)
Organization: CIS Dept, Univ of Linkoping, Sweden
Lines: 88

In article <1568.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes:
>
>??? PREFIX message passing operator?  I haven't seen that go by, could
>you elaborate?

The issue is how to apply messages. If we look at it from the syntax
level point of view we have to handle the parameters, the object, and
the message. Using an active message style (function) would look like
this:
	<parameters> <object> <message>
        "10 10 aPoint moveTo"
If the message is passive a prefix message-passing function could be 
used:
	<parameters> <object> SEND <message>
        "10 10 aPoint SEND moveTo"
Or even prefixing the object:
	<parameters> <message> SENDTO <object>
	"10 10 moveTo SENDTO aPoint"
I believe the first style to be the "natural" choice and it blends nicely
with forth.

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

Implementing a OOP extension will have to be a hybrid solution much
like C++, Simula, and Turbo Pascal 5.0. Data will be divided into 
the groups objects, and primitive data types such as integers, float, 
etc. Going all the way to a full object oriented language such as 
Smalltalk-80 puts a large overhead on the basic computational
model and we will lose "forth". We also have to decide if classes
should be objects. In this case we will need meta-classes. Most
hybrid languages such as the ones above view the class and a language
construct, not an object, and a large amount of the class information
is lost at compile-time. In forth we can take some advantage of
this information (instance-variable schema, super class pointer etc).

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

What I am looking for (thinking about, and designing) is an extension
that is not bound to an implementation. More a specification of
an interface. So far I have designed and experimented with three basic 
models of OOP in forth; relations, prototypes (or also called slot based),
and the class-instance model. These are all available in the next 
release. I'm just doing some more testing (gamma-testing) and making
some more examples.

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

The order of the parameters to the class "messages" have the class as
the top parameter. The "send" function should locate the message given
the class.  The object is a parameter to the method (self). The
implementation of the word "message" could look something like this:
	
	: message ( -- )
	  create-message
	does> ( object message -- object)
          over class send
        ;

A message word is active and performs the send operation. But the "send"
word can also be used when creating proxy-objects. The "TraceableObject"
is an example of this. Allowing access to the message-passing mechanism
give more modeling freedom.

>-Doug

Thanks for your comments! I'd love to see some more postings on this
subject. We havn't come to the real hard decisions yet. Garbage Collection.
Persistence. Multiple inheritance. And of cause, a class hierarchy for
abstract data types; sets, tuples, mappings, and sequences.

Mikael