Dick Karpinski wrote:
"Joachim Durchholz" wrote, in part:
The concept of a class, together with dynamic dispatch, was really novel. What was not novel was the flow of control once the system had determined which routine to call. The Smalltalk literature just failed to mention this, and I had to painstakingly find this out by tracing the execution of the model VM in one of the Smalltalk books.
What I hear here is that you'd have benefitted from even a single example of the correspondence between methods and subroutines, especially if the differences were highlighted by explicit commentary. Many more may yet follow that path. Would you take an hour to create the annotated example that would address that educational goal?
Ouch... I should have kept my large mouth shut. I'm having some difficulties complying whith this one. My thinking mode is very abstract, and not using examples at all; so I'm having difficulties producing one. I'll produce a raw explanation instead; somebody with a better grasp of examples could add one. Besides, English is not my native tongue, so somebody please clean the following up.
Explanation of message sends for traditional programmers -------------------------------------------------------- You may be wondering how this all relates to the more traditional ways of programming. What "is" a message send in terms of a standard programming language? Well, it's both very traditional and novel. It is traditional in the mechanics of execution. The caller provides a set of parameter values for the message handler ((is "message handler" the right terminology?)). A message handler executes just like a subroutine: It accepts the parameter values in its formal parameters and does whatever it wants. It may have local variables, and it may return a value that will become the result of the call. What's not so traditional is the process that selects the message handler. ((Add a reference to the following topics here: (a) overriding, (b) dynamic binding, (c) polymorphism.))
Another thing that should be explained to OO programmers is that Smalltalk classes are just implementation inheritance; Smalltalk has no types, so there is no interface inheritance. What's closest to a type in Smalltalk is called a "protocol" here. (I have mentioned elsewhere in this list that Smalltalk might benefit from formalizing the protocols, but that's an entirely different issue.)
Regards, Joachim