🚀 go-pugleaf

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:
> The term
> "message" as in "unary message", "binary message", "keyword message"
> (same page and book as above), is always used to denote the message
> selector plus the arguments, that is a procedure call:
>
>	receiver messageSelector: messageArgument.
>
> which is the equivalent of
>
>	messageSelector(receiver,messageArgument);

And what exactly is your implied semantics of that
`selector(receiver,...)'? If by that construct you mean a plain function
application (like in C), that is *wrong*.  

Such syntax transformation would be correct for CLOS, but there
`selector' would be a generic function, not a usual one, so it wouldn't
work as an illustration that a message send is a "plain" function call
anyway.  (Actor also uses a function-like syntax but actually does a
runtime method lookep based on the first argument's type).

The difference is in runtime lookup, as it was pointed out by David, but
you didn't get the point:

>David> Sending has two steps in Smalltalk:
>David> (1) LOOKUP [...]
>David> (2) INVOCATION [...]
>
>Perhaps you would be amused by the mistakes in any introductory level
>book on compiler technology, for therein it is described how lookup and
>invocation are done exactly the same in any language that has procedure
>calls, and Smalltalk is not at all special in this.

Lookup is done in Smalltalk at runtime and that is *more* than just a
difference in implementation, as you try to argue.  Take this example:

	| stuff |
	stuff := aCircle.
	stuff draw.
	stuff := aRectangle.
	stuff draw

and transform it using your proposed "equivalent" (to some kind of
pseudo-C):

	stuff = aCircle;
	draw (stuff);
	stuff = aRectangle;
	draw (stuff);

These two calls to "draw" CANNOT be function calls in C sense--with
functions to apply determined at compile-time (they can only if
implementation (1) below is used).  There are two possibilities to
implement the above code to work properly:

(1) in C, geometric object should have manifest types, and `draw' should
dispatch to a proper piece of drawing code based on the object type.

(2) in C++, each of these two calls would be `stuff->draw()', `stuff'
declared as something like `GeometricObject *stuff', and `draw' declared
as (pure, most probably) virtual function in `GeometricObject' and
redefined properly in subclasses.

Both of these options actually involve a runtime lookup.

> But whether the lookup or invocation are done at runtime or compiletime
> does not matter; all languages must first resolve an interface to an
> implementation and then run the implementation. Either can be left to
> runtime, or done at compiletime if possible.

Right, "if  possible".  The point is, it is not always possible. 
Polymorphism is about not knowing the exact type of an object while
using it, and compile-time lookup is impossible without knowing the
exact object type.

>I think that this curious idea is another of the bad consequences of
>poor terminology in Smalltalk... Confusing names with concepts is a very
>common activity in this newsgroup, and no doubt it has illustrious
>precedent.

Confusing plain function application with a message send is a very
common activity among people who don't understand Smalltalk messages,
CLOS or Dylan generic functions, or even C++ virtual functions, and no
doubt it has illustrious precedent.


--Vassili