Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!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: <11444@medusa.cs.purdue.edu>
Date: 23 Aug 90 23:57:27 GMT
References: <11425@medusa.cs.purdue.edu> <1569.UUL1.3#5129@willett.pgh.pa.us>
Organization: Department of Computer Science, Purdue University
Lines: 64

In article <1569.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes:
>
>here.  What you seem to be saying is:  I can only imagine that OOF is
>implemented by using indirect function calls.  Therefore, there is no
>reason to hide that fact from the OOF extensions.

   Not at the expense of efficiency and simplicity. In a language that
   doesn't try to be consistently post/pre fix, why do you insist that
   the syntax for OO be perfectly postfix? I just don't think the order
   of message-object is that big a deal. So use whichever way costs less
   in the implementation. I am able to read the OO abstraction into either
   syntax, just as I can read word definition into either
   : zzy ... ;   or   { ... } "zzy" define         .
 
>No, I think inconsistency is ugly.  In order to do delayed sends you

   What inconsistency?

>are going to have to play stack manipulation games.  In your scheme
>you write delayed sends differently because you have no choice.  In

   No, you have no choice!

>my scheme, delayed sends are easily accomplished by controlling when
>SEND is executed.  I claim that my way is more consistent, is simpler,

   Same thing with my scheme.

>and is still in the spirit of Forth.  I consider having to do
>SWAP EXECUTE ugly.  It is gratuitous stack manipulation.  I think that
>gratuitous stack manipulation is ugly.  I also think it indicates that
>the factoring involved is not as good as it could be.

   You can claim all you want, but you haven't shown anything! You give
   me a single example where my method would need to swap and yours wouldn't
   and then claim my method is "not as good". I can turn around and give
   you an example where yours would need to swap and mine wouldn't. That
   proves nothing! Are you trying to say that forth should have no "swap"?

   The discussion thus far:

   I give the best implementation I can think of and show how the
   object-message syntax matches that implementation more cleanly than
   the message-object syntax. 

   People object to me letting the implementation reflect in the syntax as
   it somehow offends their OO ideals.

   I claim that in forth the implementation has always been reflected in
   the syntax, so that is not a very strong objection. (eg. It is obvious
   from the syntax that there is a stack hiding back there somewhere.)

   People claim I don't understand forth or OO.

   Oh, you really got me there! Ohh. Ohhh.  8^)

   Now here is some vague claim that my implementation is "not as good" as
   some other one that hasn't even been specified! My implementation is
   inconsistent? I have yet to see "your way". I challenge you to give an
   implementation that fits your chosen syntax and fits as cleanly with forth
   as the one I gave for my syntax. If you could do that, I would probably
   prefer your syntax too. ... naaaaaah!
-- 
Bill <bouma@cs.purdue.edu>      Just ask the Axis   He knows everything