At 6:39 PM -0400 8/11/99, Stephen Pope wrote:

[snip]
>Apart from the obvious faster method lookup, why *should* Smalltalk
>treat two methods with the same keywords but different keyword order as
>unique methods?

{Note that someone, Travis?, implemented keyword order independant selectors.}

>Exanmples:
>	Boolean ifTrue:ifFalse vs. ifFalse:ifTrue
>	Rectangle left:top:right:bottom vs left:right:bottom:top
>	Dictionary case:otherwise: vs. otherwise:case

Last one seems to be the killer for me. I don't ever want to see
otherwise:case:. It doesn't scan well for me.

>Any ideas?

I *don't* think of ifTrue:ifFalse: as a mere order varient of
ifFalse:ifTrue, just as I don't think of ifTrue: as an ifTrue:ifFalse with
an optional keyword surpressed. While implementationally, it'd probably be
nice to be able to automagically generate certain permutations, the main
reason I see for enforcing keyword order is that I tend to learn the
selector as a whole. *Good* selectors become easy to use because they have
a certain "beat" to them--they make sentences. By generally enforcing
keyword order you can encourage certain--very general--styles (ack! not
that again! :)). (Besides, espescially with the selector finder, they're so
easy to look up there's no excuse.)

Take the one that really matters: Rectangle left:top:right:bottom. I don't
like this selector, but ok. I'd be happier with the following idiom:
	Rectangle new left: 0;
				  right: 100;
				  top: 0;
				  bottom: 100.

i.e., a cascade. Of course, I can have any order I like (side effects
aside). So I suspect that when keyword order independance beckons, it's
because you really should have a cascade, *except* in certain, well
defined, cases. But there, you don't *just* have keyword independance, you
have varients on a theme and that variation should carry some (pragmatic)
significance.

More mindless speculation.

Cheers,
Bijan Parsia.