One reason could be to better model English-like language structure. The
order of the keywords ideally should form a "sentence" (in the natural
language meaning of the term) when put together with the arguments --
arbitrary keyword order would render this powerful associative tool
useless.

Collection has a number of messages of at least semantically order
dependent form: things like #collect:thenSelect:, #remove:ifAbsent:,
#detect:ifNone: -- and Dan's whole #adaptToXxxx:andSend: mechanism.
Personally, I don't see the keywords of a selector as separate entities,
but more as parts of a "fill in the blanks" phrase - when you've filled
in the "blanks" you have a complete message to send. IMHO, someone who
asks you this question is looking at things in the wrong way to begin
with. (If what you're referring to is how the method's implementation
actually handles the arguments of the keywords - then I don't see how
the order would matter at that point.)

Allowing an arbitrary ordering of keywords to map to a single selector
would be very painful to read and understand -- recognition of
programming idioms would become nearly impossible. A method containing
just four selectors with three keywords each would have at least 3!**4
different ways it could be written (and ordered - since changing keyword
order would necessarily change the ordering of the arguments) to do
exactly the same thing -- and that's assuming the order of the selectors
within the method does not change.

Now having a tool to straighten out any misordering of keywords (with a
corresponding reordering of arguments) in one's code might be a nice
thing to have around.

-- Dwight

Stephen Pope wrote:
> 
> Hello all,
> 
> I was just talking to a colleague who's a Java programmer interested in
> Smalltalk, and I could not come up with a meaningful example of when
> keyword order really matters in a method body. (It can of course matter
> in what order you compute the arguments in the calling method, in case
> the preparation of one argument has side-effects that influence the
> value of another method.)
> 
> Apart from the obvious faster method lookup, why *should* Smalltalk
> treat two methods with the same keywords but different keyword order as
> unique methods?
> 
> Exanmples:
>         Boolean ifTrue:ifFalse vs. ifFalse:ifTrue
>         Rectangle left:top:right:bottom vs left:right:bottom:top
>         Dictionary case:otherwise: vs. otherwise:case
> 
> Any ideas?
> 
> stp
> 
> --
> 
> Stephen Travis Pope  --  http://www.create.ucsb.edu/~stp
> stp at create.ucsb.edu  --  stp9 at cornell.edu