Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!udel!carroll
From: carroll@udel.edu (Mark Carroll <MC>)
Newsgroups: comp.lang.forth
Subject: Re: ... and zen there were objects.
Message-ID: <28039@nigel.ee.udel.edu>
Date: 21 Aug 90 14:00:36 GMT
References: <11406@medusa.cs.purdue.edu> <27883@nigel.ee.udel.edu> <11418@medusa.cs.purdue.edu>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 131
Nntp-Posting-Host: dewey.udel.edu

In article <11418@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes:
]In article <27883@nigel.ee.udel.edu> carroll@udel.edu (Mark Carroll <MC>) writes:
]]In article <11406@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes:
]]]   
]]]   However some OO pusher wants to look at things the fact of the
]]]   implementation remains! The message is basically just an indirect
]]]   function call. I'll assume we agree on this. 
]]
]]I've got to disagree here. It's true that on the implementation level,
]]a "message pass" is a special kind of indirect function call. But if
]
]  So we do agree then! First you disagree with the fact and then you
]  say that it is true. Please try to be less wishy-washy.
]

I'm simultaneously agreeing and disagreeing. Implementationally, a
message pass is nothing more than an indirected function call. But, to
say that object-oriented programming is nothing more than programming
with indirected function calls misses the point. Object-oriented
programming represents a different approach, and to trivialize it into
indirect function calls loses the real point of object-oriented
programming. Indirect function calls are just a tool that make a new
approach possible - they're not the entirety of the new approach.

]]you think of it as being "just an indirect function call", then you've
]]missed the entire point of object-oriented programming.
]
]  Oh, so what you really dissagree with is my honesty. The OO abstraction
]  is very useful for handling certain problems, but let's not confuse it
]  with what is really goin on.
]

There's an important point to be found is this disagreement: What do
we mean by "What is really going on?" It's an important question. To
me, what is really going on when we add object-orientation to Forth is
that we're adding a new computational model to the system. If that's
what's really going on, that the language constructs should be
designed to match that new model. To you (I think), what is really going
on is that we're adding an indirect functional call construct to Forth,
and you'd like to see the language constructs reflect that reality. I
don't really think that the two of us will ever agree on what we want
from an object extension.

]]Object-orientation represents a very different way of approaching a
]]problem. The benefits of object-oriented programming don't come from
]]indirect function calls - those have been around for ages, and they aren't
]]really that big a deal. The benefits comes from the difference in programming
]]style. And that object-oriented programming style derives from the difference
]]in approach. In an object-oriented programs, OBJECTS are active, FUNCTIONS
]]are passive. An object-oriented automaton has a passive processor and an
]]active store. Active objects are the entire point of object-orientation.
]  

I completely disagree with what comes next. You describe what
Object-orientation is in terms of the underlying implementation of it
on a VN machine. I don't think that an OO system can be properly described
in terms of a VN machine. The VN is equally powerful, (so an OO can be
implemented on a VN, and a VN can be implemented on an OO), but the
models are different.

]  Object oriented programming relies upon basically three computational
]  constructs:
]
]  1. Automatic association between code and a type (class) of object. This
]     is where the indirect function call comes in. If this is nothing new,
]     then OOP is just another way to look at something old. Actually
]     OO has innovation here for making it automatic. The association and
]     bookeeping is done by the system rather than explicitly by the user.
]

Object-orientation doesn't necessarily have anything to do with
classes!  Classes are not necessary in an object-oriented language.
(Self!) In fact, I believe that the best way to add oo to forth is
without classes. Forth believes in the minimal approach - and the minimal
approach to object-orientation is prototypes with delegation, not classes
with inheritance.

]  2. Multiple inheritance. A new class can include several other classes and
]     inherit data components and values from them.
]

Multiple inheritance is not necessary for Object-orientation. Smalltalk -
the first of the real object-oriented languages didn't include multiple
inheritance. And most of the time, multiple inheritance is not necessary.

]  3. Flexible inheritance of behavior. A class can inherit code from the
]     classes upon which it is built. It also has capability to modify or
]     override that behavior.
]

Again, trash the classes. The real key ability is the ability of an object
to divert a message pass to another object.

]  I don't see how you can divorce the benefits of OOP from the indirect
]  function call as you have done? That is the biggest part of what makes
]  an OO language work (1 and 3).
]

The benefits of object-oriented programming come from active objects.
Indirect function calls are just implementation level details that make
active objects possible.

]]In traditional Forth, the active entity comes last. In a normal
]]Forth program, the active entity is the word (function), so the name
]]of the word (the function name) comes last. In an object-oriented Forth 
]]program, the active entity is the OBJECT. So the name of the object should
]]come last.
]
]  Not really. The forth abstraction is that every word is active.
]  Even though it isn't implemented that way, even constants can be thought
]  of as active. For instance a number's action is to push itself onto the
]  stack. The only requirement forth puts on order is that when a word needs
]  something to be on the stack, it must be there.

In a way, you're right here. But in another way, any statement in Forth
contains certain "goal" words, where some portion of the sequence of words
preceding are just setting up for the goal, and the goal word is the really
important part of the sequence. The goal word is, in some way, the most
active part of the expression. And that goal always comes last. I still
think that for a proper implementation of object-orientation in Forth,
active objects should be the most active part of the expression.

]-- 
]Bill <bouma@cs.purdue.edu>      Just ask the Axis   He knows everything

	<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