Levente Uzonyi <leves@...> writes:
Personally, I would love to have a #gsub:with: on String. It is short and uses established vocabulary.
Please no, smalltalk is not awk or ruby and noone should expect that these cryptic function names are well known. Message names should be as descriptive as possible, this enables understanding the code without documentation. Short message names have no advantage, we are not in the 80's.
I dare to disagree :) Growing a language *and* compressing it. There is two directions for natural growth of a language. Composing complex expressions from simple ones (see Guy Steele's classic OOPSLA keynote) *and* shortening the name of often the most common operations. The latter is clearly something that should happen overtime as an evolutionary process and not up front. Akira Tanaka refers to this as the "huffman coding" of API design. I have written about that on my blog [1]. So method names should initially be as descriptive as possible, but often used method names should get a short alias. In 80 when Smalltalk was fresh, #copyReplaceAll:with: was a revolutionary short "huffman encoding" for like 20 lines of C (or worse) code. Smalltalk was visionary in using long method names in the 80ies, but to each anti-thesis there is a synthesis. Today we are 30 years later, and "gsub" has established itself as a generally known name for replacing all occurrences of a pattern in a string. IMHO it has evolved from what once used to be a cryptic function name to a proper programming term of its own. We can think of other mebbe more Smalltalkesque huffman codings also, eg 'foobarqux' at: 'bar' put: 'XYZ'. with a double dispatch on the parameter of the #at: keyword, this would even open up the API of String for unlimited extensions by clients without cluttering it with dozens of new messages. So you could use integers, strings, regeces, et cetera... Well, just brainstorming :) --AA [1]: http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/