Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp From: dwp@willett.pgh.pa.us (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: ... and zen there were objects. Message-ID: <1567.UUL1.3#5129@willett.pgh.pa.us> Date: 21 Aug 90 04:57:48 GMT References: <11418@medusa.cs.purdue.edu> Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 157 In <11418@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) 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. And you can stop being so cut-and-dried. He can disagree without having to disagree totally. (Ok, if you were kidding, I'm just kidding, if not, I'm not). > >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. And just what is really going on? The "Indirect function call" abstraction is very useful for handling certain problems... :-) Your definition of "what is really goin on" is no more or less arbitrary, capricous or correct that the one you are refuting. Levels of abstraction are not useless because they hide other levels of abstraction, quite the contrary. There are (at least) two problems with focusing on "what is really goin on". 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. Second, you tie your thinking to a level of "how" and not "what". Yes, perhaps, OOP is "like" a kind of indirection function call. BUT, it doesn't have to be. It "could be" just a big switch statement (which is not a function call of any kind). The point is the effect, not the 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 indicated Forth is a language for letting you specify "the what," instead of "the how." I would like to strive to reach that level of usage and understanding. I don't think it can be done in the way you are suggesting, which I see as focusing on "the how." > 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. Here you go again with that assumption about an implementation. Yes, it can be done that way, but that is not the only way. > 2. Multiple inheritance. A new class can include several other classes and > inherit data components and values from them. This is a topic that is far from agreed upon. I don't care to dispute it here since it isn't related to the topic at hand. Single inheritance is sufficient. If you want to require MI, I won't argue the point. > [ 3. Inheret, add or over-ride behaviour of parent class(es).] > > 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. > >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. Lets not equivocate here. Words can be active because they "do something", even if that something is only to push a number onto the parameter stack. This is your sense of active. Words can be active in that they consume data from the parameter stack, do something useful, and may even put results back onto the stack. This is the sense that I and the text you quote mean. Your definition (the first) of active is vacuously true when you consider that every word is active by virtue of causing the interpreter or compiler to "do something", such as executing or compiling it. Getting back to the original point... Look at it from an esthetic point of view (now I'm really in trouble!): Arg Arg Arg Object Message vs. Arg Arg Arg Message Object Assume that Message and Object are only one Forth word each. Which form scans most understandibly? In the first form the Object gets in the way of connecting the arguements to their Message. In the second form the arguments are more closely related to the Message. In the first form you have a mixture of post-fix style (push arguments then do actions) and prefix style (procedure name [Object] followed by argument [Message]). In the second form all arguments are pushed and the action on them invoked. How do the forms support cascading? Cascading is where one message returns an object which is the destination for the next message. In SmallTalk it looks like, say: MyRect moveToX: 3 Y: 4 Draw: Green which means: Send MyRect the message moveToXY with parameters 3,4. moveToXY returns the object to which the message was sent. That object is then send the message Draw with parameter Green. Green 3 4 MyRect moveToXY Draw vs. Green Draw 3 4 moveToXY MyRect SEND SEND Which of those scans more easily? I think that it is harder in the first example to group the message names and their arguments. In the second example message names are parameters too, so they are naturally and automatically grouped with "their" parameters. Consider even with just one message send what happens if their is non-trivial code to generate the arguments and the objec reference. That also makes it hard to see which words are associated as parameters to the message and which are words that construct the object reference. 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. -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]