Re: Higher Order Messaging
Re: Higher Order Messaging
- Subject: Re: Higher Order Messaging
- From: Raffael Cavallaro <email@hidden>
- Date: Wed, 18 Oct 2006 10:42:09 -0400
On Oct 18, 2006, at 9:32 AM, Thomas Davie wrote:
No C++, Java, Ada, Sceme... implementation I've ever seen has made
the distinction. Obj-C is the only language I've ever seen where
an object (as it should) recieves a message and then decides to
call a method based on the message name.
Look at Scheme (or Common Lisp) - tinyCLOS for Scheme or the real
item, the Common Lisp Object System. You have generic functions
(which are just "message names" with congruent lambda lists, and a
collection of method implementations each of which is specialized on
the classes and/or particular values of the parameters). Then, at
runtime (hence the dynamic bit) the method dispatch system determines
which method implementation to execute based on the generic funtion
name (a.k.a, the "message name") as well as the classes and values of
the parameters.
In other words, in single dispatch, message passing OO the "message"
is just the generic function name. We can't know until runtime which
method implementation to call because we may not yet know the class
of the receiver - indeed we may not even know the "message" if it is
dynamically generated at runtime. At runtime the OO system's dispatch
mechanism decides what method implementation to actually execute
based on a combination of the "message"/"generic function name" and
the "message reciever" (which is equivalent to specializing only on
the class of a distinguished first/self/receiver parameter).
In a multiple dispatch language the dispatch mechanism can deal with
many more specializations since we are not limited to dispatching
only on the class of the "receiver" or "self" parameter. In these
multiple dispatch languages the OO system's dispatch mechanism
decides what method implementation to actually execute based on a
combination of the generic function name (a.k.a. "message" in message
passing OO systems) and the classes and/or values of *all* the
parameters, not just some distinguished "receiver" or "self" parameter.
One key to understanding dynamic languages is to realize that much
can be and often is unknown until runtime. There can and do arise
situations in which *nothing* about a method call is known until the
program actually executes - the name of the generic function or
"message" can even be dynamically generated from user input! - and of
course the classes and values of the parameters are also often
unknown until runtime as well.
regards,
Ralph
Raffael Cavallaro, Ph.D.
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden