Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: ... and zen there were objects.
Message-ID: <11425@medusa.cs.purdue.edu>
Date: 22 Aug 90 00:49:52 GMT
References: <11418@medusa.cs.purdue.edu> <1567.UUL1.3#5129@willett.pgh.pa.us>
Organization: Department of Computer Science, Purdue University
Lines: 59

In article <1567.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes:
>
>And just what is really going on?  The "Indirect function call" abstraction
>is very useful for handling certain problems...  :-)  Your definition of
> ...
>    First, there is no objective way to decide "what is really going on."
>    You pick that by using a level of abstraction apropriate to the task at
>    hand.

  Yes, and I picked a level of abstraction appropriate to what I was
  talking about, namely, implementing OO in forth. The person I was
  replying to was trying to pull me to some higher level, saying that
  I shouldn't look at OO that way as OO is really something much more
  than that. Fine if it is, but that has nothing to do with what I was
  talking about. Contemplating OO on some high level of abstraction is
  not going to get it implemented. It seems like people think I have
  something against OO just because I stoop to the level of implementation!
  
>mechanism.  Once you determine that all OOP is "really" is is indirect
>function calls, you *have* missed the point.  CM and Wil Baden both have

  If you think of it as something more than that when you are trying
  to implement it you have really missed the point.

>Here you go again with that assumption about an implementation.  Yes, it
>can be done that way, but that is not the only way.

   As far as I know indirect function call is the only way. Please tell me
   some other way. I really would love to talk something solid here rather
   than this silly bickering over word semantics. It is easy to see that
   writing if-then statements on the fly isn't going to work. I consider
   indirect jump equivalent to indirect function call, don't you?

>>   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).
>
>OOP does not specify the mechanism buy which it works.  I don't see how you
>can focus on such a low level detail and still reap the benefits of OOP.

   But if I am to write an OO language, I MUST specify the mechanism by
   which it works! If I do not focus on such a low level detail, I will not
   have any OO to reap the benefits from!

>Consider another case.  You have a linked list object which keeps a list
>of objects.  You want to invoke a message for each object in the list.
>How to do it?  The obvious way is to have a word which pushes the
>message and its arguments onto the stack.  The linked list object
>can then walk its list, EXECUTE the word, push the current object and
>do a SEND.  In your mechanism that won't work because the object has
>to be on the stack already in order to put the message after it.  That
>means the word you pass to the linked list method must play all kinds
>of ugly stack games to work right.  My experience with Forth so far says
>that ugly stack games indicate bad factoring.

   You consider a single SWAP an ugly stack game? You should not be
   programming in forth.
-- 
Bill <bouma@cs.purdue.edu>      Just ask the Axis   He knows everything