matz:
> You're right.  Did you scan my brain lately?

Well, I tried at least :). First the power my poor home-made machinery
consumes overloaded the national network, and caused a black moment during
early morning hours. They managed to fix the outage, and connect few big
power plants from Germany too, but then it was the poor Wintoys which
crashed. Apparently you can't give it even a small task of measuring the
room temperature. You see, the scanner - long distance scanner particularly
- requires quite stabile environment.

After that there were amazing storms at sun and the result of those were
very visible. At Hokkaido, I mean. Very lively and bright Northern Lights,
Aurora Borealis. And of course, as you guess, they effectively halted the
operation of my scanner, and we're just warming it up.

So the long story short: I had to make up the rules :).

Mark Slagell:
> |A. Least Surprise is not well served by the inconsistency, 

First, I have to confess, Mark, that I fought with the issue too. Nowadays
I'm calmer, as after few surprises one gets used to that :).

However, while you're right with your claim, you have to note the
inconsistency could be detecetd only against some rule set. And in this case
the rule set is quite simple, compact, and well working:

  1) plain method name doesn't say anything about state desctructive 
     or preserving nature
  2) '!' in the end of the method name wakes you up. Now we're really
     modifying receiving object instead of the usual thing, where 
     we return a new modified object.

Thus when you read about SomeClass#act, you have to think if the name
indicates the state of the object is going to change. If the case is vague,
consult documentation.
When you see there's SomeClass#act!, you can be pretty sure there's plain
named, non-mutating version of the method, and usually it works like
someClassInstance.dup.act!.

So if your rule-set was something different, like mine was, you probably
find yourself thinking why every state-modifying method isn't named with !.
The reason is that most methods modify receiver's state, thus the code would
be full of exclamation marks. Matz did see this, and started to use another,
quite natural and little suprising, rule set. The one in my previous mail,
and above.

Here Least Surprise was dismissed for the Friendly Source code. But it
didn't manage to go far away, before there was again room for it.

> |a use for a non-destructive array insert whereas to me it might sound
> |just as natural and sensible as non-destructive string concatenation.

Humm..first, it's better to use state-modifying or something else than
destructiveness to describe or call 'methods!'. Second, what are
non-destructive string concatenation or array insert? Is non-destructive
string concatenation an operation which doesn't change the state of the
string object, thus the only possible catenation would be aString + "" and
everything else rejected with an exception. 

By the way did you notice how natural the previous aString.+("") looked.
Would you like to say aString.+!("")?

> |Naming a destructive method without the ! ties our hands 

This is very good point!

Would you like to try what it's like to live in properly named world by
creating a somewhat complete aliasing module, changing current
state-modifying methods to have an exclamation mark etc.?

If there's some real code to see, it would be fun to evaluate if there's any
ground for the claim "the code would be polluted by '!'".

	- Aleksi