Difference between += for Integers/Strings and << For Arrays?

Question 1

You see, names (variable names, like a and b) don't hold any values themselves. They simply point to a value. When you make an assignment

a = 5

then a now points to value 5, regardless of what it pointed to previously. This is important.

a = 'abcd'
b = a

Here both a and b point to the same string. But, when you do this

a += 'e'

It's actually translated to

a = a + 'e'
# a = 'abcd' + 'e'

So, name a is now bound to a new value, while b keeps pointing to "abcd".

a = [1,2,3,4]
b = a
a << 5

There's no assignment here, method << modifies existing array without replacing it. Because there's no replacement, both a and b still point to the same array and one can see the changes made to another.

Question 2

The answer to 1) and 2) of your question:

The reason why += is syntactic sugar and << is not is fairly simple: += abstracts some of the syntactic expression: a += 1 is just a short version of a = a + 1. << is a method all by itself and is not an alias for push: << can only take one argument, whereas push can take an arbitrary number of arguments: I'm demonstrating this with send here, since [1,2]<<(1,2) is syntactically incorrect:

[1,2].send(:<<, 4, 5) #=> ArgumentError: wrong number of arguments (2 for 1)

push appends all arguments to the array:

[1,2].push(4,5,6) #=> [1,2,4,5,6]

Therefore, << is an irreplaceable part of the ruby array, since there is no equivalent method. One could argue that it is some kind of syntactic sugar for push, with disregard for the differences shown above, since it makes most operations involving appending elements to an array simpler and syntactically more recognizable.

If we go deeper and have a look at the different uses of << throughout ruby:

Push An Element to an array:
```
[1,2] << 5 
```
concatenate a string to another, here, << is actually an alias for concat
```
"hello " << "world"
```

Open up the singleton class and define a method on a class:

class Foo
  class << self
    def bar
      puts 'baz'
    end
  end
end

And last but not least append self to self in Integers:
```
1 << 2 #translates to ((1 + 1) + (1 + 1))
```

We can see that << actually stands for append throughout ruby, since it always appears in a context where something is appended to something already existing. I would therefore rather argue that << is a significant part of the ruby syntax and not syntactic sugar.

And the answer to 3)

The reason why b's assignment is not modified (or wiped of its old value, as you put it) if you use the += operator is just that a += 1, as a short for a = a + 1, reassigns a's value and therefore assigns a new object along with that. << is modifying the original object. You can easily see this using the object_id:

a = 1
b = a
b.object_id == a.object_id #=> true

a += 1
b.object_id == a.object_id #=> false

a = [1,2]
b = a
b.object_id == a.object_id #=> true
a << 3
b.object_id == a.object_id #=> true

There are also some caveats to Integer instances (100, 101) and so on: the same number is always the same object, since it does not make any sense to have multiple instances of, for example 100:

a = 100
b = a
b.object_id == a.object_id #=> true
a += 1
b.object_id == a.object_id #=> false
a -= 1
b.object_id == a.object_id #=> true

This also shows that the value, or the Integer instance (100) is just assigned to the variable, so the variable itself is not an object, it just points to it.

Question 3

String#+ :: str + other_str → new_str Concatenation—Returns a new String containing other_str concatenated to str.

String#<< :: str << integer → str : Append—Concatenates the given object to str.

<< doesn't create the new object, where as + does.

Sample1:

a = 100
p a.object_id
b = a
p b.object_id
a+= 5
p a.object_id
p b.object_id
puts a
puts b

Output:

Question 4

Your example:

a = 100
b = a
a+= 5

is equivalent to:

a = 100
b = a
a = 100 + 5

Afterwards a holds a reference to 105 and b still holds a reference to 100. This is how assignment works in Ruby.

You expected += to change the object instance 100. In Ruby, however (quoting the docs):

There is effectively only one Fixnum object instance for any given integer value

So there's only one object instance for 100 and another (but always the same) one for 105. Changing 100 to 105 would change all 100's to 105. Therefore, it is not possible to modify these instances in Ruby, they are fixed.

A String instance on the other hand can be modified and unlike Integer there can be multiple instances for the same sequence of bytes:

a = "abcd"
b = "abcd"
a.equal? b # returns true only if a and b are the same object
# => false

a << "e" concatenates "e" to a, thus changing the receiver: a is still referencing the same object instance.

Other methods like a += "e" return (and assign) a new String: a would reference this new instance afterwards.

The documentation is pretty clear:

str + other_str → new_str

Concatenation—Returns a new String containing other_str concatenated to str.

str << obj → str

Append—Concatenates the given object to str.

Question 5

I can answer your questions.

1) No, the << method is not syntactic sugar for push. They are both methods with different names. You can have objects in Ruby that define one but not the other (for example String).

2) For a normal method like <<, the only thing that can happen as a result of a << x is that the object that a is pointing to gets modified. The statements a << x or a.push(x) cannot create a new object and change the variable a to point at it. That's just how Ruby works. This kind of thing is called "calling a method".

The reason that += being syntactic sugar matters is that means it can be used to modify a variable without mutating the old object that the variable used to point to. Consider a += x. That statement can modify what object a is pointing to because it is syntactic sugar for an actual assignment to a:

a = a + x

There are two things happening above. First the + method is called on a with one argument of x. Then the return value of the + method, whatever it is, is assigned to the variable a.

3) The reason that your Array case is different is because you chose to mutate the array instead of creating a new array. You could have used += to avoid mutating the array. I think that these six examples that will clear things up for you and show you what is possible in Ruby:

Strings without mutations

a = "xy"
b = a
a += "z"
p a  # => "xyz"
p b  # => "xy"

Strings with mutations

a = "xy"
b = a
a << "z"
p a  # => "xyz"
p b  # => "xyz"

Arrays without mutations

a = [1, 2, 3]
b = a
a += [4]
p a  # => [1, 2, 3, 4]
p b  # => [1, 2, 3]

Arrays with mutations

a = [1, 2, 3]
b = a
a.concat [4]
p a  # => [1, 2, 3, 4]
p b  # => [1, 2, 3, 4]

Integers without mutations

a = 100
b = a
a += 5
puts a   # => 105
puts b   # => 100

Integers with mutations

Mutating an integer is actually not possible in Ruby. Writing a = b = 89 actually does create two copies of the number 89, and the number cannot be mutated ever. Only a few, special types of objects behave like this.

Conclusion

You should think of a variable as just a name, and an object as a nameless piece of data.

All objects in Ruby can be used in an immutable way where you never actually modify the contents of an object. If you do it that way, then you don't have to worry about the b variable in our examples changing on its own; b will always point to the same object and that object will never change. The variable b will only change when you do some form of b = x.

Most objects in Ruby can be mutated. If you have several variables referring to the same object and you choose to mutate the object (e.g. by calling push), then that change will affect all the variables that are pointing to the object. You cannot mutate Symbols and Integers.

Question 6

I guess the above answers explain the reason. Note also that if you want to ensure b is no pointer, you can use b = a.dup instead of b=a (dup for duplicate )

Question 7

I'll try and answer your question to the best of my ability.

Yes, both are "sugars" but they work differently and as Sergio Tulentsev said, << it's not really a sugar but it's an alias.

And those works as an alias in Unix like languages, it's a shorter shorthand for something named after your liking.

So for the first scenario: += basically what's happening is that you're saying:

for the value 100 assign label 'a'.
for label 'b' assign the value of label 'a'.
for label 'a' take the value of label 'a' and add 5 to label 'a's value and return a new value
print label 'a' #this now holds the value 105
print label 'b' #this now holds the value 100

Under the hood of Ruby this has to do with the += returning a new String when that happens.

For the second scenario: << it's saying:

for value [1,2,3,4] assign label 'a'  
for label 'b' assign the value of label 'a'
for label 'a' do the '<<' thing on the value of label 'a'.
print label 'a'
print label 'b'

And if you're applying the << to a string it will modify the existing object and append to it.

So what's different. Well the difference is that the << sugar doesn't act like this:

a is the new value of a + 5

it acts like this:

5 into the value of 'a'

2) Because the way you use the syntactic sugar in this case is making it easier for the developer to read and understand the code. It's a shorthand.

Well, shorthands, if you call them that instead, do serve diffrent purposes. The syntactic sugar isn't homogenous ie. it doesn't work the same way for all "sugars".

3) On wiping values:

It's like this.

put value 100 into the label 'a'
put the value of label 'a' into label 'b'
remove label 'a' from the value.

So

a = 100
b = a
a = nil
puts a
puts b
=> 100

Variables in Ruby doesn't hold values they point to values!