Message sends and function calls--terminology 
Author Message
 Message sends and function calls--terminology

In talking with a colleague whose expertise includes heavy
experience with c-LOS (an object-oriented LISP), we discovered that
there was a signficant divergence of our understanding of the term
"message" in OOP.

To him, a "message" is a lexical notation that syntactically
distinquishes a "receiver."  Method names can be overloaded.

To me and most other Smalltalk programmers, a "message" is the lexical
invocation of an abstract function such that the actual function is
determined at run time by dynamic dispatch.  A method is a function
selected for execution by dynamic dispatch based on 1) a message
selector, and 2) the distinguished argument of the function which
we call the "receiver of the message".

Concrete examples:

                                    Red             Blue
Syntax            Call mechanics    Terminology     Terminology

"print(anObject)" static dispatch   function call   function call

"print(anObject)" dynamic dispatch  function call   message send

"anObject print"  dynamic dispatch  message send    message send

"anObject.print()" static dispatch  message send    (overloaded)
                                                    function call

This difference in terminology leads to serious misunderstandings.

There is no right and wrong here.  But until this inconsistency in
terminology is fixed somehow, confusion and unnecessary arguments
will be common.  If you think this topic is only of relevance
for c-LOS, note that the same terminology difference exists between
the Smalltalk and C++ communities (for example).

The obvious thing that can be done about this is to be aware of the
difference in terminology, and be very careful what terms you use
unless you know your audience shares your terminology.  What else can
be done, I don't know.

--Alan Lovejoy

P.S.  I am aware of virtual functions in C++ (for example).  Whether
virtual functions are methods in "Blue Terminology" is an interesting
topic.  If you want to discuss it, please start a new thread, and
remove any irrelevant newsgroups from the discussion.  I'd suggest
comp.lang.c++ and comp.object as the only clearly relevant groups.



Fri, 29 May 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:

>In talking with a colleague whose expertise includes heavy
>experience with c-LOS (an object-oriented LISP), we discovered that
>there was a signficant divergence of our understanding of the term
>"message" in OOP.

>To him, a "message" is a lexical notation that syntactically
>distinquishes a "receiver."  Method names can be overloaded.

This doesn't make much sense, for the simple reason that CLOS doesn't have
"message" as a construct. CLOS has methods and generic functions: no
"sending" and no "messages". So wherever your colleague got his peculiar
notions, it wasn't from CLOS.

One of the important Lisp oop precursors to CLOS was Flavors, which in its
original incantation did have messages and explicit message sending (with
the function #'send). Here a message has essentially the same semantics as
in Smalltalk, although the syntax is different.

Quote:
>To me and most other Smalltalk programmers, a "message" is the lexical
>invocation of an abstract function such that the actual function is
>determined at run time by dynamic dispatch.

Exactly what it is in Flavors. And, since CLOS doesn't have messages,
there's no conflict in either case.

Quote:
>A method is a function
>selected for execution by dynamic dispatch based on 1) a message
>selector

As in Flavors and CLOS

Quote:
>and 2) the distinguished argument of the function which
>we call the "receiver of the message".

As in Flavors. CLOS and other languages (eg Dylan) which support the more
general concept of multi-argument dispatch don't designate a specific
"receiver", but the principle is the same; one would say "the specialized
arguments to the generic function" rather than "the receiver of the
message"

Quote:
>This difference in terminology leads to serious misunderstandings.

You're making a mountain out of the molehill of your friend's personal
misunderstand of "message".

Quote:
>If you think this topic is only of relevance
>for c-LOS, note that the same terminology difference exists between
>the Smalltalk and C++ communities (for example).

C++ doesn't have messages or message-sending either.

The term "method" can only be used in C++ as a rough analog of what it
means in other languages. In other words. it's better not to use it at
all. There's a reason C++ uses "member function" and "virtual member
function" instead.

In sum, in languages where "message" and "message sending" have meaning,
those meanings are more or less identical to one another. In languages
where "method" has a meaning, those meanings are quite similar to one
another except for the distinction mentioned above (single vs multiple
dispatch). There's really no room for confusion.

--



Sat, 30 May 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:



>>In talking with a colleague whose expertise includes heavy
>>experience with c-LOS (an object-oriented LISP), we discovered that
>>there was a signficant divergence of our understanding of the term
>>"message" in OOP.

>>To him, a "message" is a lexical notation that syntactically
>>distinquishes a "receiver."  Method names can be overloaded.
>This doesn't make much sense, for the simple reason that CLOS doesn't have
>"message" as a construct. CLOS has methods and generic functions: no
>"sending" and no "messages". So wherever your colleague got his peculiar
>notions, it wasn't from CLOS....

Did Alan say that I thought CLOS had messages?  No, he didn't.
His words above are in any case his own paraphrase of what I
said.  The Reader's Digest version, if you will (sorry, Alan).  I also
elaborated by email in response to his email of the above, but we
need not go into that here.  As far as I'm concerned, one's exact
definition of "message" isn't as important as the knowledge that
the concept isn't unique and isn't an indispensible characteristic
of OO.

Quote:
>>...This difference in terminology leads to serious misunderstandings.
>You're making a mountain out of the molehill of your friend's personal
>misunderstand of "message".

He may be making something out of something else, but you
are without any doubt making a lot of assumptions here.  The
misunderstanding he refers to is not between him and me, but
it *is* rather widespread in the OO community.  We got onto
this topic because of posts on another newsgroup reflecting
misconceptions which I would summarize as "messaging is
fundamentally different from function calling, and understanding
the difference is essential to proper use of language X."  So far,
I have yet to see anyone *justify* such an assertion.

A related misconception sometimes expressed is that asyn-
chronous messaging, as in actor languages, is fundamentally
different.

Quote:
>....
>In sum, in languages where "message" and "message sending" have meaning,
>those meanings are more or less identical to one another.

I'm not familiar with many "messaging-based" languages,
but from what I understand those meanings are not always
identical.  Actor type languages and perhaps others are
different in significant (if not fundamental) ways.

Quote:
>In languages
>where "method" has a meaning, those meanings are quite similar to one
>another except for the distinction mentioned above (single vs multiple
>dispatch).

Various kinds of methods (daemons, etc.) and method combination,
dynamic versus static inheritance, privacy constraints, roles, and
other factors contribute to quite a bit of variation here.  Differences
may be less significant than similarities, but they are significant.

Quote:
> There's really no room for confusion.

Seriously?  It seems to me that when as many beginners are
entering an evolving domain as are entering OO recently,
there's always "room for confusion."  This is especially true
when beliefs of a religious flavor start to creep in, which
seems to happen with annoying regularity (just to avoid any
confusion: that last isn't a message about anything so far on
this thread).

Another way to look at it is that when you stop being
confused, you stop learning.



Sat, 30 May 1998 03:00:00 GMT  
 Message sends and function calls--terminology

goochb> We got onto this topic because of posts on another newsgroup
goochb> reflecting misconceptions which I would summarize as "messaging
goochb> is fundamentally different from function calling, and
goochb> understanding the difference is essential to proper use of
goochb> language X."  So far, I have yet to see anyone *justify* such an
goochb> assertion.

goochb> A related misconception sometimes expressed is that asyn-
goochb> chronous messaging, as in actor languages, is fundamentally
goochb> different.

For what reasons is that a misconception?



Sun, 31 May 1998 03:00:00 GMT  
 Message sends and function calls--terminology


Quote:

>In talking with a colleague whose expertise includes heavy
>experience with c-LOS (an object-oriented LISP), we discovered that
>there was a signficant divergence of our understanding of the term
>"message" in OOP.

>To him, a "message" is a lexical notation that syntactically
>distinquishes a "receiver."  Method names can be overloaded.

>To me and most other Smalltalk programmers, a "message" is the lexical
>invocation of an abstract function such that the actual function is
>determined at run time by dynamic dispatch.  A method is a function
>selected for execution by dynamic dispatch based on 1) a message
>selector, and 2) the distinguished argument of the function which
>we call the "receiver of the message".

        In the Oberon System, a message is still different.  
It's taken rather literally and is a data record passed to an
object's message handler.  "Method" often refers to the
procedures used to implement a handler.  

Quote:
>The obvious thing that can be done about this is to be aware of the
>difference in terminology, and be very careful what terms you use
>unless you know your audience shares your terminology.  What else can
>be done, I don't know.

        Personally, I'm not positive that something else needs
to be done.  I'm comfortable with leaving the ideas of
objects, messages, etc. to OO *design* and letting the
implementation details of OO *programming* vary between
languages and applications.  The important thing would be to
remember that there is a distinction between messaging and the
way you do messaging, for example.  

--
Twenty dollars can buy many peanuts!  -- Homer Simpson



Sun, 31 May 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:

>Another way to look at it is that when you stop being
>confused, you stop learning.

True enough, but there are so many *new* things to be confused about, I'd
just as soon leave the old, settled things alone.

I'll try to exit gracefully now from this unintended light-flame-war (I
have nothing but respect for Mr Gooch) and go back to waiting for UPS to
deliver my Dylan Technology Release...

--



Sun, 31 May 1998 03:00:00 GMT  
 Message sends and function calls--terminology

:...
: Another way to look at it is that when you stop being
: confused, you stop learning.

In a sense.  As one learns you are less confused about some things, you
_know_ more.  Yet, the new understanding most often raises other points,
which can be confusing.  And then one tackles the new points, and the
cycle goes on and on.  So yes, one is often constantly confused about
certain points, but the level of knowledge, and confusion generally rises
to a higher level as the cycle "spins".

Elliott



Mon, 01 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:


>goochb> A related misconception sometimes expressed is that asyn-
>goochb> chronous messaging, as in actor languages, is fundamentally
>goochb> different.
>For what reasons is that a misconception?

The short answer is: because synchronous messaging plus
threads is equivalent to asynchronous messaging.


Tue, 02 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology



  goochb> A related misconception sometimes expressed is that asyn-
  goochb> chronous messaging, as in actor languages, is fundamentally
  goochb> different.

piercarl> For what reasons is that a misconception?

goochb> The short answer is: because synchronous messaging plus
goochb> threads is equivalent to asynchronous messaging.

That's an answer to a different question, one concerning the difference
between asynchronous and synchronous messaging (plus threads), but if I
remember well the context seemed to be about differences between actor
messaging and ``messaging''/function calls. Let's check...

Yeah, looking back at the other paragraph to which I was referring to as
the context of my question:

  goochb> We got onto this topic because of posts on another newsgroup
  goochb> reflecting misconceptions which I would summarize as
                     ^^^^^^^^^^^^^^
  goochb> "messaging is fundamentally different from function calling,
           ^^^^^^^^^    ^^^^^^^^^^^^^^^^^^^^^^^      ^^^^^^^^^^^^^^^^

That this is a misconception is agreed, BTW.

  goochb> and understanding the difference is essential to proper use of
  goochb> language X."

  goochb> A related misconception sometimes expressed is that asyn-
          ^^^^^^^^^^^^^^^^^^^^^^^
  goochb> chronous messaging, as in actor languages, is fundamentally
  goochb> different.

  For what reasons is that a misconception?

it seemed to me that you were criticizing as a misconception the
difference between messaging/calling (as described in the first
paragraph) and actor messaging, not with synchronous messaging (plus
threads), that was not explicitly mentioned.

As to the difference I (erroneously?) thought you were addressing
(``messaging''/calling vs. actor messaging), there are very solid
reasons for which one can argue that actor messaging is fundamentally
different from ``messaging''/procedure calling, whether synchronous or
asynchronous, local or remote (indeed actor computing is often claimed
to involve a different computation model from conventional languages),
like that it involves transfer of data but not transfer of control, and
that the exchange patterns of those data do not need to be nested,
instead of being nested like control transfers in procedure calling
(``messaging'' to some).



Wed, 03 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:

>.... one can argue that actor messaging is fundamentally
>different from ``messaging''/procedure calling, whether synchronous or
>asynchronous, local or remote (indeed actor computing is often claimed
>to involve a different computation model from conventional languages),

In the abstract, I suppose it could be viewed as "fundamentally
different," and even "to involve a different computation model."
But in a practical sense, is there anything fundamentally different
about simulating actor behavior on sequential hardware, versus
the sort of language that it might be simulated in?  Unless we are
really talking about some non-conventional hardware, in which
case the difference may be something fundamental.  If not, is there
something you can point to that one can do in an actor language
that can't be done in a C, C++, Smalltalk or CLOS with threads?

Quote:
>like that it involves transfer of data but not transfer of control, and
>that the exchange patterns of those data do not need to be nested,
>instead of being nested like control transfers in procedure calling
>(``messaging'' to some).

Asynchronous messaging via conventional messaging with threads
does not involve transfer of control.


Thu, 04 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:

> In talking with a colleague whose expertise includes heavy
> experience with c-LOS (an object-oriented LISP), we discovered that
> there was a signficant divergence of our understanding of the term
> "message" in OOP.

I have never liked the use of the word "message" to characterise OOP,
partly because it tends to imply OOP is inherently inefficient because of
communication overheads, but also because it does not convey an accurate
impression of the fundamental concepts of OO.

Basically, an object is characterised by a set of externally visible
attributes ("attributes" used in a wider sense than in Eiffel) which can
be accessed/invoked from the environment in which the object exists. In
abstract terms, access/invocation has no messaging connotations but the
effects can (sometimes) be described easily using messaging as an analogy.
In reality, in some systems but by no means all, implementation of
attribute access/invocation may be accomplished by the use of messaging
and indeed, in certain types of system, e.g. distributed systems,
messaging may be necessary. The point I am trying to make is that
messaging is not part of the OO paradigm but in certain situations it may
be a desirable or even essential implementation technique.

Quote:
> The obvious thing that can be done about this is to be aware of the
> difference in terminology, and be very careful what terms you use
> unless you know your audience shares your terminology.  What else can
> be done, I don't know.

It has long been my experience that the lack of a rigorous terminology for
OOP is a great impediment to conducting discussions in depth about various
important aspects.

Cheers....Ron

------------------------------------------------------------------------
  Ron Kerr, Computing Service, Newcastle University, NE1 7RU, England.
 Tel. +44 191 222 8187       Fax. +44 191 222 8765  (NOTE new area code)
------------------------------------------------------------------------



Mon, 08 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology
    "Basically, an object is characterised by a set of externally visible
attributes... which can be accessed/invoked from the environment in which
the object exists."

I think I disagree. If you ask (in Smalltalk) "Random new next" to obtain
a random integer, are you accessing (or even invoking) an attribute?

I think of "attribute" as "state," and if anything, an object should
protect its state, NOT make it "externally visible." Perhaps we aren't
using the same definition of "attribute?"

Jan



2002 Parkside Ct., West Linn, OR 97068, USA +1 503 657 7703



Mon, 08 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:

> I think of "attribute" as "state," and if anything, an object should
> protect its state, NOT make it "externally visible." Perhaps we aren't
> using the same definition of "attribute?"

I think that's the key point to this thread: different people use
different terminology and it makes it difficult to talk about OOP concepts
in general. I interpreted the previous use of "attribute" to mean state
and/or "procedures", "functions", "methods", "function members" or any
other executable "attribute" of an object, not just "data".

For example: In the case of some languages, such as Dylan, all the
"slots", or "state" as you put it, are accessed via functions. In fact, in
Dylan slots can be declared "virtual", in which case there is no storage
allocated for them at all and they effectively exist only because there
are functions to access them*.

Therefore, I don't see much difference between protected, internal state
"data" and externally visible ones when the visible "attributes" may be
functions and the internal representation of the state externally
presented by those functions is hidden. (Unfortunately, some languages,
such as C++, require you to distinguish between "data members" and
"function members".)

*If this sounds confusing, imagine an object that represents a rectangle
whose internal representation is a pair of top/left & bottom/right
coordinates. You may wish to present "attributes" of the rectangle such as
top/left & width/height, four corner coordinates, center position & size,
or any other derivative you can imagine. In Dylan, you just allocate
"real" slots for your "real" internal representation and declare "virtual"
slots for the other external representations. You can then feel free to
change the internal representation, while still allowing any of the
several convenient external representations who may or may not be "real"
slots.

--
Chris Page        | Internet chain letters, adverti{*filter*}ts and SPAMs suck...
Don't Panic!      |



Tue, 09 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology

:     "Basically, an object is characterised by a set of externally visible
: attributes... which can be accessed/invoked from the environment in which
: the object exists."

: I think I disagree. If you ask (in Smalltalk) "Random new next" to obtain
: a random integer, are you accessing (or even invoking) an attribute?

: I think of "attribute" as "state," and if anything, an object should
: protect its state, NOT make it "externally visible." Perhaps we aren't
: using the same definition of "attribute?"

: Jan

I don't think you are using the same definition of attribute. All
instances with the same dynamic type have the same attributes. That
is, a class defines a set of attributes which are common to all
instances of that class. Each instance then has its own state -
i.e. attributes are assigned different values.

In Smalltalk, all data is private and all methods are public (I can't
say I'm an expert in Smalltalk jargon... but I think I'm pretty close :)
This is not how encapsulation is handled in all OO languages. But most,
if not all, agree there should be a public interface and a private
implementation. That is how an object protects its state... by only
permitting access through its interface. Again, it is dependant on the
language as to how this is accomplished.

Eric



Tue, 09 Jun 1998 03:00:00 GMT  
 Message sends and function calls--terminology

Quote:

>    "Basically, an object is characterised by a set of externally visible
>attributes... which can be accessed/invoked from the environment in which
>the object exists."

>I think I disagree. If you ask (in Smalltalk) "Random new next" to obtain
>a random integer, are you accessing (or even invoking) an attribute?

>I think of "attribute" as "state," and if anything, an object should
>protect its state, NOT make it "externally visible." Perhaps we aren't
>using the same definition of "attribute?"

>Jan



>2002 Parkside Ct., West Linn, OR 97068, USA +1 503 657 7703

Not having read the original post....
I don't think Kerr means 'attribute' and 'instance variable' as synomymous.  I believe
 the poster means as 'something that can be used to characterize or describe
 the object'  Or 'soemthing which is attributable to the object'.  For example,
  in an Invoice object, you could consider totalCost to be an 'attribute',
 although it is probably not an instance variable.  totalCost is probably a method
 that iterates over linetems and answers the total cost of all lineItems plus a
certain tax rate.  (In Smalltalk lingo...)

        totalCost
                | total |
                total := 0.
                self lineItems do: [: item |
                        total := total + item itemCost
                ].

                ^total + TaxPolicy taxForAmount: total

totalCost is a method that performs a calculation, not an instance variable, but
 from a client's (any user of Invoice) perspective, it could be considered an
'Attribute' of Invoice objects in that it characterizes or describes them or their
 current state.
With such a mentality, I believe, in Random new next, next could be considered
 an Attribute of instances of Random, even though it is a method, not an
instance variable.

I suppose this distinction would only apply to methods that treated the receiver
 as a subject of the verb rather than the object of the verb.  In my mentality,
 their are two kinds of methods.  Those where the receiver of the message
 is the target of the method, and those where the receiver is the performer of the
method....Hmmm that may not sound right.  How 'bout

        object goDoSomething.
  or    object tellMeSomething.

        window open.
  or    window width.

        I think Kerr meant by Attribute something akin to Responsibilities
 (in CRC) regardless of how that respnsibility is implemented (by instance variable
 or method).  I hope this helps.        

James O'Connor
Framework Technolgoies



Tue, 09 Jun 1998 03:00:00 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Message sends and function calls--terminology

2. Message sends and function calls--terminology

3. Message sends and function calls--terminology

4. Message sends and function calls--terminology

5. Message sends and function calls--terminology

6. Message sends and function calls--te

7. Replace standard MESSAGE function in C4 with own message function

8. VC++ calling fortran function and fortran function calling a c++ function

9. send mail using SMTP Send Message when mail server is unknown

10. How to find out name of calling function from called function

11. Calling functions from functions from functions ...

12. A message send logger in a runtime application...

 

 
Powered by phpBB® Forum Software