Levente Uzonyi <le...@...> 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/
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
