Ron Jeffries <ronjeffries / REMOVEacm.org> wrote in message news:<74CECE8B145DE9C3.0F4503436A495466.1AD19ECF5ED70FB3 / lp.airnews.net>...
> On Sun, 02 Dec 2001 18:03:12 -0500, Panu Viljamaa <panu / fcc.net>
> wrote:
> 
> >Yes I have. What happened was I find it hard to understand how to
use a method written by someone else when there is no indication of
what kind of arguments should be passed to it.  It is also hard to say
if it is right or wrong when there is no clearly written contract on
"what it should do".  This might be specified by some test-case-class
somewhere, but I'd rather have 'contract' of the method visible as
soon as I view the method's source, so I don't have to go test-case
hunting.
> 
> The usual Smalltalk convention is to write a method defintion like
> this:
> 
>   insert: anObject into: aCollection
> 
> which means about the same thing as
> 
>   void insert( Object o, Collection c)
> 
> The name of the method, insert:into: is chosen to reflect what the
> method should do.

I'm all for intention revealing selectors (and more generally,
intention revealing names), but you left out a discussion 
of tradeoffs in naming parameters after their types
vs their roles in the method.

Furthermore, your example raises a question about how revealing
this particular selector is:
The Collection class has a selector for inserting elements.
Seeing a method such as
     #insert: AnObject into: aCollection
         aCollection add: anObject.
makes me question the quality of the design.
More likely #insert:into: does more than insert, 
but then it should have a different name - 
one that reflects the semantics of the domain.

Marc Gluch
Mindtap Inc.