At 07:31 AM 1/28/98 -0500, you wrote:
I personally prefer case-sensitive languages to case-insensitive languages. If I want to have selectors or procedures named abc, Abc, ABC, and aBc in a program I darn well expect the language to allow it and not try to limit what can be done. I also *HATE* underscores and dashes in identifier, selector, or procedure names. If I wanted to PROGRAM-IN-COBOL or PROGRAM_IN_PL_1 <gag!> I'd do so. I don't. Keep Smalltalk case-sensitive!!!! :-)
If a define a class with two methods >>aBc and >>aBC, how can I tell the differences between them without going into the implementation? For more hypothetical examples, how about
asArrayofKeywords vs >>asArrayOfKeywords
asBytesArrayEncoding:into: vs asBytesArrayEncoding:Into:
asUInt32 vs >>asUint32
There are no standards or rules at all. And people do make mistakes when typing.
We use case sensitive method signature to help us to *read* the method more easily. It should not change the *meaning* of a method.
Thanks. -- Mark Wai Frontier Systems Architecture Inc. mailto: mwai@ibm.net or:[ mwai@frontiersa.com] __
I wonder if some of this pressure to change Squeak method lookup rules would disappear if the spelling checker were a little more agressive. I find the continuous correction in recent versions of Word to be both helpful and polite. I'm still incline to check capitalization in the browser as I'm writing my methods, but I don't think I would mind watching the capitalization pop in from all lower case typing. -- Ward
mARK wAI wrote:
There are no standards or rules at all. And people do make mistakes when typing.
so 100 mW = 100 MW ?
I actually once had methods in Number like that. Ssomeyhing like:
mW ^Power value: self / 1000.
MW ^Power value: self * 1000000.
Wim Boot
squeak-dev@lists.squeakfoundation.org