Case-insensitive selectors

Reinier L.J.M.W. van Loon R.L.J.M.W.van.Loon at inter.nl.net
Thu Jan 29 19:10:32 UTC 1998


What I understand from the discussion is that Mark Wai does not want to
change the case-ness of words. He simply wants the method lookup to ignore
case. This is not a bad idea.
OTOH, what I really like about Smalltalk is the way it approaches natural
language (in this case English). Capitalization is done for readability and
only (IMHO) because spaces are not allowed in selectors. I.e. you would
like to write 'this is how natural language looks like' but end up with
'thisIsHowNaturalLanguageLooksLike'. So, the rule I use is: 'Write it out
in natural language and then replace each space and it following character
with the capitalized version of that character'. This leaves no ambiguity.
To repeat some examples:

unsigned integer 32 bits	->	UnsignedInteger32Bits	-> UInt32
as lower case		->	asLowerCase
as array of keywords	-> 	asArrayOfKeywords

The abbreviation of UInt32 is a bit dirty but can be deduced using the rule
(I never abbreviate selectors). In the case there are parameters you would
write in natural language:

as byte array encoding x into y	-> asByteArrayEncoding: x into: y

I.e. the rule is: do not capitalize after a parameter.

The first rule cannot be detected by the compiler (unless you supply a
dictonairy or have it look at other selectors), the second can supported by
the compiler.
Furthermore, I like to mention to Mark Wai that Squeak does help a bit when
you save a method and it does not recognize a selector (and lets you choose
another).

Last but not least: I am not amused by using the underscore symbol ( _ )
for assignment. Try converting a piece of Visual Smalltalk code with symbol
like: #UP_RIGHT, #DOWN_LEFT. You can't file this is in without editing!

Hope this helps.





More information about the Squeak-dev mailing list