On Sun, 17 Oct 2004 13:02:38 -0700, Andres Valloud <sqrmax at cox.net> wrote:

> sd> For me I would like to get something that tell me:
> sd> 	this argument receives the messages of TSortable
>
> Hmmm... how about naming the argument aTSortable?... can't the code
> just be clear?  What is the gain of adding something to support
> comments if apparently we're not properly commenting the code (thus
> needing extra comments or annotations)?...

What if you need two or more? anInteger, anotherInteger, aThirdInteger.<s>

There seems to be a lot of layers to this issue:

1. The method designer, if he's designated a class that he wants to  
receive, can get help from the environment about available methods.

2. The method consumer (terrible word, but...) can then get help from the  
environment about which of the available objects conform to the method's  
parameters.

3. In some languages this works in an LCD fashion: the method accepts  
parameters of class X or any of its descendents. Smalltalk isn't that  
rigid, so it would probably be better for the method to accept parameters  
of any class that could receive the messages required.

The trick is making step 1 not too cumbersome--and managing step 3. What  
you get in exchange is guidance making the right choice when calling a  
method.