3

I've been bitten a couple of times by forgetting that x = y in Ruby makes x refer to the same object as y; I'm too used to languages where it means, in Ruby terms, x = y.dup. Forgetting this, I inadvertently change y when I think it's safe on the right side of the assignment.

I can see that it would make sense to avoid simple x = y assignments without a special reason, but the same thing can be lurking in other places such as 

name = (person.last_name.blank? ? 'unknown' : person.last_name)

where a later name << title would actually be changing person.last_name and not just name.

If this has happened to you, too, how have you learned to avoid it? Are there certain red flags or patterns to look for? Do you look with suspicion at each assignment you make? Do you use .dup a lot? I don't know if Ruby's usage will ever become second nature to me, so any useful tips would be welcome.

Mike Blyth
  • 4,158
  • 4
  • 30
  • 41
  • Just curious, what language(s) are you coming from to Ruby? – Mladen Jablanović Mar 26 '11 at 16:01
  • Mladen -- mainly short forays into various ones from 6510 & IBM 360 assembly to PL/I, Pascal, C++, Forth. Not an expert in any ... ordinarily my real job is being a physician. – Mike Blyth Mar 26 '11 at 18:53
  • In my opinion, it's one of those things you have to pay attention to when programming. Pascal used `:=` for assignment and `=` for comparison, interpreted BASIC used `=` for both, Perl uses `eq` for string comparison and `==` for numeric comparison and `=` for assignment, and basically you have to keep them all straight in your head. That's why commenting, writing clean and understandable code is so important; It's hard enough revisiting code written months or years ago, and then add in a different language with its uniquenesses... it's enough to make your brain pop. – the Tin Man Mar 27 '11 at 01:49

4 Answers4

5

This may sound unorthodox in a (essentially imperative) language like Ruby, but my advice is: avoid collateral damages by not updating objects at all (except when strictly necessary); create new ones instead. You pay a bit of performance but you'll get code which is clearer, more compact, more modular and easier to debug.

http://en.wikipedia.org/wiki/Functional_programming

So, in your example, just create a new string with a new name:

complete_name = name + title
Mike Blyth
  • 4,158
  • 4
  • 30
  • 41
tokland
  • 66,169
  • 13
  • 144
  • 170
  • 3
    In other words, use `name += title` instead of `name << title` above. – Mladen Jablanović Mar 26 '11 at 15:59
  • 1
    @Mladen. Not quite, if you took a functional approach then you'd create a new string: name_with_title = name + title. Question updated to make it clear. – tokland Mar 26 '11 at 17:57
  • 1
    +1 For functional programming. I wish my colleagues would understand that principle... – fresskoma Mar 26 '11 at 18:30
  • 1
    `name += title` _does create_ new string (but assigns it a same name `name`). – Mladen Jablanović Mar 26 '11 at 18:56
  • 1
    @Mladen: I know, but reusing the same name is not advisable. As you know, this is one of the advantages of FP, when you see an assignment (name binding, in strict functional languages), you know for sure it will have this same value in all its scope. – tokland Mar 26 '11 at 19:39
1

Just an addition to tokland's answer:

Functional approach insists on immutability - i.e. not altering existing objects, but creating another whenever you want to change the original one. This is somewhat against the object-orientated paradigm that Ruby also brings (objects keep their state internally, which can be altered by calling methods on it), so you have to balance a bit between the two approaches (on the other hand, we benefit by having multiple paradigms easily accessible in a single language).

So, three things to remember for now:

  1. Learn what assignment in Ruby is: nothing but naming an object. So, when you say y=x, you are only saying "we give another name y to whatever was named x".
  2. name << title mutates object called name.
  3. name += title takes objects named name and title, concatenates them into another object, and assigns that new object name name. It doesn't mutate anything.
Mladen Jablanović
  • 43,461
  • 10
  • 90
  • 113
  • I agree, strict functional programming and Ruby's classical OOP are sometimes difficult (or impossible) to fit together. My personal rule is to try to stay functional as much as I can; when you need to change the state of an object, so be it. – tokland Mar 28 '11 at 09:51
0

I also came across such a situation and it resulted in a bug, which I took half a day to figure out. I essentially did something like this

hash = {....}
filename = object.file_name
hash.each |k, v| {file_name.gsub!(k, v) if file_name.include? k}

This code was inside a loop and in the loop, I expected the variable file_name to be again set to original value. But the object.file_name was changed, as I was performing file_name.gsub!. There are 2 ways to solve this. Either replace the .gsub! call with file_name = file_name.gsub or do file_name = object.file_name.dup. I opted for the second option.

I think we should be careful with methods having ! and <<, as they change the original object on which they are acting, especially after assignments like this.

rubyprince
  • 17,559
  • 11
  • 64
  • 104
  • a functional approach would be way shorter: hash.inject(object.file_name) { |string, (k, v)| string.gsub(k, v) } – tokland Mar 26 '11 at 18:29
  • tokland--I'm interested in learning more about using the functional approach ... I've only played with Haskell a little bit. Where could I learn more about using it with Ruby? – Mike Blyth Mar 26 '11 at 18:45
  • @tokland..I have heard of functional programming but never had a chance to really try and understand it..and yes..that would have been much shorter.. – rubyprince Mar 27 '11 at 18:04
  • 1
    @mike, @rubyprince. I wrote an article on Ruby idioms where I cover functional constructions a little bit. I am planing on writing something specific about FP with Ruby, I'll post the URL here. For now: http://code.google.com/p/tokland/wiki/RubyIdioms – tokland Mar 28 '11 at 09:55
0

A method should not modify a variable (e.g. by using the shift operator) unless its definition says it will modify it.

So: never modify an object in a method that didn't either (a) create it or (b) document that it modifies it.

John Douthat
  • 40,711
  • 10
  • 69
  • 66