Path: utzoo!attcan!uunet!cs.utexas.edu!husc6!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: ... and zen there were objects.
Message-ID: <11418@medusa.cs.purdue.edu>
Date: 21 Aug 90 00:25:30 GMT
References: <11376@medusa.cs.purdue.edu> <1533.UUL1.3#5129@willett.pgh.pa.us> <11406@medusa.cs.purdue.edu> <27883@nigel.ee.udel.edu>
Organization: Department of Computer Science, Purdue University
Lines: 62

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.

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

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

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

  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.

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

>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.
-- 
Bill <bouma@cs.purdue.edu>      Just ask the Axis   He knows everything