From: Mark Slagell <ms@...>
Date: 2000-10-21T06:54:35+09:00
Subject: [ruby-talk:5721] Re: Array#insert

Aleksi Niemel� wrote:
> 
> . . .
> as "insert before" or "insert after".  Think of it
> > as "insert at".
> 
> Very good discussion. Guy's right about better semantics, Mark about real
> meaning of semantics, and Jim about proposing the way to understand how
> negative indexes work.

Being entirely satisfied with Jim's "insert at" explanation, I withdraw
my objection. :-)

> ...
>
> > BTW, shouldn't the method be named "insert!" ?
> 
> I think I'm following matz ideas when I named it to be "insert" instead of
> "insert!". And the reasoning is that currently the methods are not named
> with exclamation mark (!) if
> 
> 1) the name clearly indicates the receiving object is going to change and/or
> 2) there's no corresponding method with implicit dup.
> ...

This is in fact one of the first things that startled me when learning
about ruby. I'll give three reasons for wishing we were consistent about
!/? naming:

A. Least Surprise is not well served by the inconsistency, IMO. I'd love
to be able to reliably know, when seeing the name of an unfamilar
method, whether it is can be trusted not to change the receiver.

B. Getting used to having garbage collection has made me more
comfortable with programming in a functional style, as it's easier to
reason about the behavior of non-destructive methods. So it is a nice
convenience for me when destructive methods routinely turn out to have
non-destructive equivalents. I guess what I'm saying is that "clearly
indicates" is anything but clear much of the time, and is open to honest
disagreement based on differing styles; for instance, you might not see
a use for a non-destructive array insert whereas to me it might sound
just as natural and sensible as non-destructive string concatenation.

C. (related to B, but this applies even if you don't consistently prefer
functional style) Naming a destructive method without the ! ties our
hands - what can we do if we later change our mind later about the need
for a non-destructive equivalent?

 -- Mark