Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mailrus!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: ... and zen there were objects.
Message-ID: <11406@medusa.cs.purdue.edu>
Date: 18 Aug 90 06:23:12 GMT
References: <11376@medusa.cs.purdue.edu> <1533.UUL1.3#5129@willett.pgh.pa.us>
Organization: Department of Computer Science, Purdue University
Lines: 66

In article <1533.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes:
>In <11376@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes:
>
>>     'traditional' language looks like. I would say the syntax with the
>>     message at the end is really the most forth-like. The function usually
>>     comes at the end in forth. The message is basically just an indirect
>>     function call.
>
>I must disagree here.  Your view is still the traditional NON OO view
>of functions with arguments.  OO says just the opposite.  OO says that it
>is the object which is interesting/important.  The message is a thing which
>is passed to the object and which the object examines and does with as it
>sees fit.  The message is just another parameter of sorts.  Your style
>re-asserts the functional style in which the object is a parameter to the
>function.  Not a common view of OO systems as I understand them.

   So wich of us is being more traditional? 8^)
   
   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. Then, getting back to
   tradition, what is the traditional forth way of doing things? I would
   say it is to take the easy way, the simplest is the best. So think of
   implementing such a beast. The way I propose, the message can be a
   normal forth word that simply does the indirection given the object
   on the stack. The object can be just some data address plus a tag to
   identify its "class". Your way can be implemented pretty much the same
   way (SEE BELOW), but then why bother to hide the implementation at the
   cost of lost efficiency? There would be an even greater loss of effic-
   iency if it was implemented the way you describe its functionality.
   Consider: A message has to be either a word that
   pushes some ID onto the stack, or a string. Both are awkward. Then an
   object instance has to be a word with run time behavior of reading the
   message off the stack, pushing its data address on the stack, and 
   finally executing the identified function. But an object instance
   is really a piece of data and thus you should be able to store it in
   a variable plus you need to access the data address. You NEED "SEND" ...
>
>There is one other point you made which I think is independant of the
>"inside-outness" issue.    Constant message names versus "anonymous"
>message names.  That is, message names known at compile time versus
>message names found on the stack at run time.  That strikes me as a
>purely efficiency consideration.  I don't yet think I know if it is
>possible to encompass both with one simple and powerful purely postfix
>(my defitition of postfix) syntax.
>
   Let's review:

   Your way: ... message object SEND
     My way: ... object message       ( : SEND execute ; )

   I hope what I have said above makes it clear that this is indeed a
   matter of efficiency. (At the very least my way requires one less "swap"
   or "push".) Also that these issues are not in the slightest "independent".
   Suppose your way was implemented my way. Then you would have to type:

   ... ' message object SEND      ( : SEND swap execute ; )

   What does this gain you? A feeling that you are doing it the OO way.
   My way fits in easily with the way forth is already setup. It is 
   cleaner, faster, and doesn't try to hide the implementation. So even
   if you believe "message object" is in some way more postfix than
   "object message", forth traditionally trashes postfixedness for the 
   sake of clarity (typing less) and simplicity. 
-- 
Bill <bouma@cs.purdue.edu>      Just ask the Axis   He knows everything