From: matz@... (Yukihiro Matsumoto) Date: 2000-07-07T12:05:06+09:00 Subject: [ruby-talk:03890] Re: Array.uniq! returning nil Hi, In message "[ruby-talk:03882] Re: Array.uniq! returning nil" on 00/07/06, Aleksi Niemel� writes: |> Basicly one should use copying (non-bang) version of the |> methods. | |Why's that so? I mean it's a nice policy, but then we should be using it as |consistenly (and much) as possible. But that's not good for performance. 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. If I create these methods from scratch, it is possible for me to make the bang methods always return self. But CHANGING behavior will crash fair amount of programs. Only options I can think of are: (a) introduce new methods (but not gsub!? please) (b) introduce additional optional argument (as Hugh proposed in [ruby-talk:03863]) |I can see: | | a = ["fo", "ha"].collect do |txt| txt+"r" end | |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. |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. matz.