[ruby-talk:03931] Re: Array.uniq! returning nil

> Well, modifying may cause confusion.  For example,
> 
>   a = "my name is matz."
>   b = a
>   a.sub!(/matz/, "Aleksi")
>   puts a
>   # prints "my name is Aleksi", it's OK.
>   puts b
>   # prints "my name is Aleksi", too.  it may be confusing.
> 
> Bang methods should be used by the expert who is taking one's risk.
> That's why bang-methods contains ugly bang sign.

Don't get me wrong here. I've understood your point, but I just want to make
sure I've not gone to wrong direction.

  a = "my name is stupid"
  b = a

  a.concat " foobar"
  puts a
  # prints "my name is stupid foobar", it's OK

  a.sub(/foobar/, "Aleksi")
  puts a
  # prints "my name is foobar", maybe quite confusing
  # following same logic as concat everybody is expecting 
  # "my name is stupid Aleksi"

  puts b
  # prints "my name is foobar", it's OK.

Well, I think we both know what we're talking about. Ruby way 'usually copy
and then self-modify' is ok for me. It just takes few exercises to remember
agains my expectations.

> |should have been (forced and) coded as
> |
> |  addR = proc do |txt| txt+"r" end
> |  a = ["fo", "ha"].collect(addR)
> |
> |In the latter example the self-modifying part is splitted.
> 
> This chunk of code does not contain self-modifying part.

Uh, yep, you're right. Should have been [].collect! instead. Anyway, my
point was that if we go with 'split self-modifying code into separate rows'
rule of thumb then it would be natural to be consistent with it. My example
was absurd just to show, there's no point, so the rule of thumb becomes
'split self-modifying method! calls into separate rows'.

> |Well, my strongest argument is yet to come. If the 
> difference between method
> |and method! would be just the fact the latter modifies 
> in-place, it'd be:
> |1) easy to learn
> |2) easy to remember
> |3) and most of all, very easy to make performance changes to 
> the existing
> |   code
> 
> If bang-methods does not have nasty (well, kinda) side-effect, I'd
> love to make them default (non-bang) to enhance total performance.
> But sadly we have to choose either performance or side-effect.  Only
> thing I can do is put the warning sign (both name and behavior) to
> tell them it's relatively (and slightly) danger.

Yup, I agree. Side-effects are bad! Performance is good! But not for any
cost. This was not, however, what I was talking about. I was pointing that
there should be consistent mapping between method and method!. If it would
be the fact that the latter operates on receiver rather than
receiver.dup.method!, the rule would be easy to learn and remember. If you
have to remember that there's quite probably additional steps to take, it's
ok too, just harder. If those steps require use of idioms 

  b = (a=[1,2,3,2].uniq!; a).unshift(-1)

or rearranging of code

  b = [1,2,3]
  b.uniq!
  b.unshift(-1)

it's much harder.

	- Aleksi