[ruby-talk:5764] Re: Array#insert

> > By the way did you notice how natural the previous 
> > aString.+("") looked.
> > Would you like to say aString.+!("")?
> 
> Maybe I'm missing something here.  All I was trying to say is that
> everybody recognizes the naturalness, and usefulness, of string
> concatenation that doesn't modify the receiver, as in the "+" 
> operator, which returns a different string.  

Nope, it was me who misunderstood. Yup, what you say makes much sense. 

> It isn't so obvious to everyone that it might be nice to have an 
> array insert method that returns a shallow
> copy of the array reflecting the results of the specified 
> insertion. 

While it might not be obvious, as you say, there's one catch here. Assume
Array#insert would have been named Array#insert!:

  class Array
    def insert
      dup.insert!
    end
  end

But if you have only non-state-modifying version, plain Array#insert,
there's no way one can go to other direction.

Now, if we're not going to implement two methods, it's clear we should have
state-modifying version, as we always can create non-state-modifying
version. The next thing is naming. As we are not going to implement two
methods, current Ruby naming framework suggests plain insert.

Then after all the discussion so far, it all comes to whether
state-modifying insert is badly named when there's no sign about it's
nature.

  def update(anArray)
    @theArray.insert(@index, anArray)
  end

For me it's obvious (or I should put, I expect) insert in above code does
change @theArray. A side effect which would create a new array, change it
and finally return would be dangerous.

If that side effect is needed the code @theArray.dup.insert(@index, anArray)
communicates programmers intention explicitly.

Anyway, this discussion has enlargened my view for Ruby name issues.
Previously I considered naming having to be conformant to OO-centered world.
That world suggests state-modifying plain names when obvious. 

> So, instead I suggest standardizing a way to name a
>   2. ends in '_': receiver's state guaranteed not to change.

I think the idea is quite good as it isn't pervasive. Anyway the difference
between

   myInteresting.object.code.dup.partly_destroy.to_s    and
   myInteresting.object.code.partly_destroy_.to_s

isn't many chars and the psychological distance with in the end of the line
gets smaller and smaller, so the coder has to be very careful.

	- Aleksi