🚀 go-pugleaf

>>> On 28 Oct 1995 14:20:51 GMT, David N. Smith <dnsmith@watson.ibm.com> said:

David> In article <46qk9j$mgv@news.inc.net> Karen Jacqmin-Adams,
David> kadams@froglit.scitele.com references the comment:

>>>> One of the big problems with Smalltalk is the extremely misleading
>>>> termonology used therein, e.g. 'message' for 'procedure' and
>>>> 'sending' for 'calling'.

Please note that this is a typo: as implied by the context, and as I
have written in a followup, it should read "'message' for 'procedure
[call]' ...".

David> ***    Sending and Calling are NOT the same.    ***

A curious novelty! After twenty years and more of Smalltalk, we
discover a new point of view. Let's see if it has some interest...

David> A method is a procedure. One COULD use the terms interchangably,
David> but it isn't done.

For purely historical reasons, perhaps. Or perhaps because it helps
cvreating a jargon, and this helps OO consultants pay the bills. Or
perhaps because it does emphasize that overload resolution is meant to
be class based.

But I suspect that the real reason lies in Smalltalk-72's mixed ancestry
as a Logo-looking version of Simula-67: for Smalltalk-72 methods began
with the keyword 'TO' (page 11, "Bits of history, words of advice"), and
indeed the natural jargon was to describe it as a "method to ...".

David> The term 'method' does emphasizes that it is part of an object
David> and not just a standalone bit of code.

Ah, this is just another of the many common Smalltalk/OO misconceptions:
In Smalltalk methods are never part of objects, but they are always
denoted by the class of an object, just as in all class based OO languages.

Perhaps you should revise your Smalltalk, e.g. the concept of class
dictionary. The point that in Smalltalk methods are _never_ part of an
object, but always of its class, is the fundamental reason for the the
existence of metaclasses: for the class methods such as 'new' cannot
belong to the class object, but must belong to the class object's class
(this is obscured in Objective-C, where factory methods look like
belonging to the class object, which is not really the case), and thus
one must ahave a notion of metaclass, so that class methods can belong
to some metaclass.

The mistake you make is common; a lot of people, among them even Berard
(e.g. his introduction to OO readable on his WWW site), are totally
confused by the "object oriented" moniker and write as if OO were about
relationships among objects instead of (as a rule) among (a type of
modules called) classes.

"object oriented" is a terribly misleading label, and I have already
spent enough pithy verbiage on this point. So please don't be misled by
the label (unless of course you deal with prototype based OO languages,
but not many do -- almost all popular OO languages are class based).

David> A message is the NAME of a method, not the method itself.

Perhaps in "David's Smalltalk", which in this as in many other respects
is rather different from Smalltalk-80: but in Smalltalk-80 the NAME of a
method is called the message "selector" (see page 37, "The language and
its implementation", section "Summary of terminology"). 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);

but for a slightly different syntax, and where the "keyword message" is

	messageSelector:messageArgument

Note that this obscures the fact that really the procedure call includes
as an argument the receiver too.

David> Sending has two steps in Smalltalk:

David> (1) LOOKUP -- Given a message name (or method name since they are
David> the same) -- find the one method in the context of the receiver
David> that has the same name.

David> (2) INVOCATION -- Start up that method. This part is EXACTLY the
David> same as calling a procedure.

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.

Just the one "special" (but it's special only to those that have a
somewhat narrow knowledge of language varieties, let me add) thing that
Smalltalk has is that LOOKUP is done at runtime instead of compiletime
contrarily to most, but not all, non OO languages. Yet there are OO
languages that always (e.g. POOL-T) or by default (.e.g C++) do the
lookup at compiletime, and there are non OO languages that do the same.

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.

For example *invocation* can be done at compiletime too, if a function
(call) has got only constant arguments (and many compilers actually do,
e.g. '3+4' is usually LOOKUP'ed at compiletime, yielding 'operator
"+"(int,int)', which is then executed immediately, and '7' is the result
of lookup and invocation done at compiletime).

  Interestingly, if I remember well, for the sake of efficiency _some_
  Smalltalk compilers do optimize away at compile time both resolution
  and execution for the fundamental classes/selectors, so that it is not
  lo longer strictly true that their Smalltalk is a 'pure' OO language:
  '3 + 4' will continue to be '7' even if you redefine '+' for
  'SmallInteger' to be the same as '*'.  In the default Smalltalk-80
  bytecode bytecode compiler this optimization is not done, and full
  runtime resolution is always the case (page 563, "Primitive methods"
  in "The language and is implementation").

David> Sending is a bigger concept that calling; a much bigger
David> concept. It is what makes OOP special.

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.

  For example in "Bits of history, words of advice" I read at the
  beginngin of the abstract of of "An assessment of Method-Lookup Caches
  for Smalltalk-80 Implementations": "A unique feature of the
  Smalltalk-80 language is the dynamic binding of methods to a message
  based on the class of its receiver.".