Dispatch on what? (Was: seeking ideas for short lecture on type classes)

John Hörnkvist john@toastedmarshmallow.com
Tue, 4 Feb 2003 16:51:18 +0100


On Tuesday, February 4, 2003, at 03:46 PM, Jerzy Karczmarczuk wrote:

> I would say that - unless I am dead wrong, the OO languages such as 
> Smalltalk
> do not dispatch on dynamic types of a value. The receiver is known, so 
> its vir.
> f. table (belonging to the receiver's class) is known as well, the 
> dispatching
> is based on the *message identifiers* independently of subsidiary 
> arguments.

Yes, normally only the receiver and "message identifier" matters. In 
languages like Java, where the type of the other arguments is 
considered, this is handled statically.

For languages like Smalltalk, Objective-C, etc, all that you know at 
compile time is that the receiver is an object. You don't know what 
kind of object. Thus you cannot use a static dispatch style or vtables 
as you would in a language like C++. Even when the type is bounded, 
vtables are not enough because of "categories" and "method packages" 
that add methods to classes at run time.

Dispatch is done on the "target" (receiver) and "selector" (message 
identifier).

So if you consider an expression like:
	target_expr doSomething:arg_expr
then you should break that up into
	v = target_expr
	f = lookup_method(v, "doSomething:")
	f(v, "doSomething:", argexpr).

You dispatch on the dynamic type of the target (it's class) and on the 
dynamic state of its method tables. Note that you cannot assume that 
the receiver has a method that matches the selector!

Dynamic method lookup is a fairly complicated and expensive process, 
and it's a barrier to many optimizations. This can be mitigated by 
program analysis and specialization or similar techniques; dynamic 
dispatch and the surrounding problems are getting fairly well 
researched.

Languages with dynamic dispatch:
* Brad J Cox, Object oriented programming: an evolutionary approach, 
Addison-Wesley Longman Publishing Co., Inc., 1986
* Apple Computer, Inc., The Objective-C Programming Language, 2002.
   http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/index.html
* Pieter J. Schoenmaker, Supporting the Evolution of Software, Ph.D. 
thesis, Eindhoven University of Technology, July 1, 1999.

Some research:
* Zoran Budimlic, Ken Kennedy, and Jeff Piper, The cost of being 
object-oriented: A preliminary study, Scientific Computing 7(2), 1999
* David Detlefs and Ole Agesen, Inlining of Virtual Methods, Proc. of 
13th ECOOP
* A Diwan. Understanding and improving the performance of modern 
programming
     languages. Ph.D. thesis, University of Massachusetts at Amherst. 
1997
* Peeter Laud, Analysis for Object Inlining in Java; 
http://citeseer.nj.nec.com/laud01analysis.html
* Ole Agesen and Jens Palsberg and Michael I. Schwartzbach, Type 
Inference of {SELF}: Analysis of Objects with Dynamic and Multiple 
Inheritance, Lecture Notes in Computer Science, 
http://citeseer.nj.nec.com/agesen93type.html

> Only after that - perhaps - some "reversions", message propagation 
> depending on
> the arg(s) value(s), etc. may take place, but all this is irrelevant...

Well,  "self" and the "selector" is usually an argument to the method, 
but otherwise I agree.

Regards,
John Hornkvist