On Nov 18, 2004, at 4:11 PM, Alexandre Bergel wrote:
>>> I do not like the multidispatch of slate but this I like.
>>
>> It's your loss. ;-) The multiple dispatch makes most of the really
>> interesting collaboration code a breeze and allows us to do things
>> which I always thought Smalltalk should be able to do but no one ever
>> conceived to actually do. Run-time scope generalization of this
>> dispatch setup also allows us to do "subjective programming" cheaply,
>> which gets us AOP features without a lot of hassle (though we still
>> don't have generalized join-points).
>
> Can you provide an example ? I was always sceptical about  
> multidispatch.

Well, the reason fits in a nutshell. Do you like /having/ to always  
define a method from exactly one perspective, and generalizing by  
having to recurse through others' perspectives, or would you rather  
just define the participation all at once? Once you start being able to  
do this (you can still recurse when it's more sensible to organize code  
that way, and we do), it adds up.

It's the difference between having to write:

XCanvas draw: shape
	shape beDrawOnXCanvas: self
(implement further method...)

and:

canvas(must be an XCanvas) draw: triangle(must be a Triangle)
(implement the method)

(The "must" parts being optional on either side.)

My partner Lee Salzman's slideshow on PMD (prototypes and multiple  
dispatch) gives an intuitive picture of the effect on code in the  
small:
http://tunes.org/~eihrul/talk.pdf

Of course, we're not selling multiple-dispatch itself. We're selling a  
combination of features, or rather, a combination of generalizations of  
Smalltalk-80 semantics.

> When I read the work on Cecil and MultiJava I do not see some really  
> good example that make me say "Oh yes, I want this language feature!".

Research languages? You must be kidding! That's like getting an  
impression about prototypes by looking at Self and Cecil - both of them  
are research and don't leverage anything of theirs to create truly  
comprehensive demonstrations of their power (that's another  
discussion).

My point is that multiple dispatch does not make a convincing  
difference in the small. It makes a difference in the /large/, which  
research systems like those can't demonstrate. When you're talking  
about getting a lot of code into one system (even just picking  
arbitrary pairs of things), the single-dispatch limitation just doesn't  
add up. You need double-dispatch patterns, visitors, module annotations  
to say that the method you're adding to class X really belongs in  
module Y (see Squeak's recent method category notation system), and so  
on and it all makes the curve more concave rather than flat in terms of  
effort.

In Slate, there are no visitors unless we really need another kind of  
object in the system, in which case it's not really a visitor but a  
collaborator. Methods belong to packages, not to classes, and you can  
get perspective-spanning methods where two objects agree to play in a  
shared space, rather than having to toss messages across a wall to get  
anything done extensibly. (I'm not arguing against encapsulation,  
instead it means that objects can participate in localized ways that  
don't introduce design interdependencies; somewhat like  
beDrawnOnXCanvas:.)

> I am really curious to see how MD bring more expressiveness.

In Slate, it's difficult to isolate entirely; often in Slate we are  
dispatching on individual objects or symbols as well or "attributed  
traits" (traits local as attributes of other traits - think of  
parametrized stream types for anything in the system - which we have!).  
My canonical example is the generalized dimensioned-units library:

http://slate.tunes.org/cgi-bin/viewcvs.cgi/*checkout*/slate/src/lib/ 
dimensioned.slate?rev=HEAD&sortby=date&content-type=text/plain

It is derived from a free Smalltalk library which had a huge amount of  
double-dispatch and was prohibitive to work with. The Slate version had  
Three Times fewer methods, and is actually something you can digest in  
terms of the amount of information needed to understand an interaction.  
It took me a few days just to get a correct overview of the system.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/