string = "test"
suitable_inventories = [1, 2, 3]
inventories ||= string.empty? ? suitable_inventories : []
inventories
Based on my understanding of Ruby, I was expecting the above code to produce:
[]
Instead, it is returning:
[1, 2, 3]
Did I misunderstand how ||= works?
||= is a conditional assignment. The below two are basically equivalent:
foo ||= 42
bar = 42 unless bar
In other words ||= will do an assignment only if the variable holds nil or false as a value ATM. Due to some peculiarities, this also means variable that didn't have a value assigned already.
So if inventories already holds some array, a new one will not be reassigned with ||=.
a ||= b means a || a = b that is,
If a is set (not nil or false), then a remains as it is, using short-circuit behaviour of || operator
Otherwise, a will be false or nil resulting in execution of second part of expression after ||, i.e a=b
In your case, inventories must be already assigned (not nil) thats why it is not []
inventories ||= string.empty? ? suitable_inventories : []
is equivalent to :
inventories || inventories = string.empty? ? suitable_inventories : []
From what I understand, a ||= 7 means the following:
if a has a value, continue using that value, but if it does NOT have one, then set it to 7.
Here is what happens though.
If i have a and b as:
a = true
b = false
then
a ||= b => true
(in my interpretation: since 'a' DOES have a value, it remains that, and does not get equated to 'false' - so far so good.)
However, if i have them switched up like:
a = false
b = true
then a ||= b => true
so in this case my logic does not work, since it should return false, as "since 'a' has a value, it should not be assigned the value of 'b'", which apparently happens here.
Am I missing something?
a ||= b
is equivalent to
a || a = b
this means b value is assigned to a if a is falsy, i.e. false or nil.
I'm confused about the different results I'm getting when performing simple addition/concatenation on integers, strings and arrays in Ruby. I was under the impression that when assigning variable b to a (see below), and then changing the value of a, that b would remain the same. And it does so in the first two examples. But when I modify Array a in the 3rd example, both a and b are modified.
a = 100
b = a
a+= 5
puts a
puts b
a = 'abcd'
b = a
a += 'e'
puts a
puts b
a = [1,2,3,4]
b = a
a << 5
puts a.inspect
puts b.inspect
The following is what was returned in Terminal for the above code:
Ricks-MacBook-Pro:programs rickthomas$ ruby variablework.rb
105
100
abcde
abcd
[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
Ricks-MacBook-Pro:programs rickthomas$
I was given the following explanation by my programming instructor:
Assigning something to a new variable is just giving it an additional label, it doesn't make a copy.
It looks like += is a method, just like <<, and so you'd expect it to behave similarly. But in reality, it's "syntactic sugar", something added to the language to make things easier on developers.
When you run a += 1, Ruby converts that to a = a + 1.
In this case, we're not modifying the Fixnum in a. Instead, we're actually re-assigning on top of it, effectively blowing away the previous value of a.
On the other hand, when you run b << "c", you're modifying the underlying Array by appending the String "c" to it.
My questions are these:
1) He mentions syntactic sugar, but isn't that also what << is, i.e. syntactic sugar for the .push method?
2) Why would it matter if += is syntactic sugar or a more formal method? If there is some difference between the two, then doesn't that mean my previously-understood of syntactic sugar ("syntax within a programming language that is designed to make things easier to read or to express") is incomplete, since this isn't its only purpose?
3) If assigning b to a doesn't make a copy of a, then why doesn't wiping away a's old value mean that b's old value is also wiped away for all 3 cases (Integer, String and Array)?
As you can see, I'm pretty turned around on something that I thought I understood until now. Any help is much appreciated!
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.
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.
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:
201
201
211
201
105
100
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.
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.
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 )
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!
I need to establish a number of Hashes, and I didn't want to list one per line, like this
a = Hash.new
b = Hash.new
I also new that apart from for Fixnums, I could not do this
a = b = Hash.new
because both a and b would reference the same object. What I could to is this
a, b, = Hash.new, Hash.new
if I had a bunch it seemed like I could also do this
a, b = [Hash.new] * 2
this works for strings, but for Hashes, they still all reference the same object, despite the fact that
[Hash.new, Hash.new] == [Hash.new] * 2
and the former works.
See the code sample below, the only error message triggered is "multiplication hash broken". Just curious why this is.
a, b, c = [String.new] * 3
a = "hi"
puts "string broken" unless b == ""
puts "not equivalent" unless [Hash.new, Hash.new, Hash.new] == [Hash.new] * 3
a, b, c = [Hash.new, Hash.new, Hash.new]
a['hi'] = :test
puts "normal hash broken" unless b == {}
a, b, c = [Hash.new] * 3
a['hi'] = :test
puts "multiplication hash broken" unless b == {}
In answer to the original question, an easy way to initialize multiple copies would be to use the Array.new(size) {|index| block } variant of Array.new
a, b = Array.new(2) { Hash.new }
a, b, c = Array.new(3) { Hash.new }
# ... and so on
On a side note, in addition to the assignment mix-up, the other seeming issue with the original is that it appears you might be making the mistake that == is comparing object references of Hash and String. Just to be clear, it doesn't.
# Hashes are considered equivalent if they have the same keys/values (or none at all)
hash1, hash2 = {}, {}
hash1 == hash1 #=> true
hash1 == hash2 #=> true
# so of course
[Hash.new, Hash.new] == [Hash.new] * 2 #=> true
# however
different_hashes = [Hash.new, Hash.new]
same_hash_twice = [Hash.new] * 2
different_hashes == same_hash_twice #=> true
different_hashes.map(&:object_id) == same_hash_twice.map(&:object_id) #=> false
My understanding is this. [String.new] * 3 does not create three String objects. It creates one, and creates a 3-element array where each element points to that same object.
The reason you don't see "string broken" is that you have assigned a to a new value. So after the line a = "hi", a refers to a new String object ("hi") while b and c still refer to the same original object ("").
The same occurs with [Hash.new] * 3; but this time you don't re-assign any variables. Rather, you modify the one Hash object by adding the key/value [hi, :test] (via a['hi'] = :test). In this step you've modified the one object referred to by a, b, and c.
Here's a contrived code example to make this more concrete:
class Thing
attr_accessor :value
def initialize(value)
#value = value
end
end
# a, b, and c all refer to the same Thing object
a, b, c = [Thing.new(0)] * 3
# Here we *modify* that object
a.value = 5
# Verify b refers to the same object as a -- outputs "5"
puts b.value
# Now *assign* a to a NEW Thing object
a = Thing.new(10)
# Verify a and b now refer to different objects -- outputs "10, 5"
puts "#{a.value}, #{b.value}"
Does that make sense?
Update: I'm no Ruby guru, so there might be a more common-sense way to do this. But if you wanted to be able to use multiplication-like syntax to initialize an array with a bunch of different objects, you might consider this approach: create an array of lambdas, then call all of them using map.
Here's what I mean:
def call_all(lambdas)
lambdas.map{ |f| f.call }
end
a, b, c = call_all([lambda{Hash.new}] * 3)
You can verify that this approach works pretty easily:
x, y, z = call_all([lambda{rand(100)}] * 3)
# This should output 3 random (probably different) numbers
puts "#{x}, #{y}, #{z}"
Update 2: I like numbers1311407's approach using Array#new a lot better.
I was under the impression that conditions joined with && were executed in sequence, such that the following would return true:
a = "adasd"
> b = a && b.present?
=> false
Thoughts?
Thanks!
--Peter
note:
b = a
=> "adasd"
b.present?
=> true
When you say this:
b = a && b.present?
You're declaring b as a local variable but it will be nil until the right side of the assignment is evaluated. In particular, b will be nil when you call present? on it and the conjunction will be false making b false.
When you do this:
a = 'pancakes'
b = a
b.present?
b will have the value 'pancakes' when you call present? on it so you get a true return from b.present?.
As per the rails doc
present is checking for a variable to be non blank
As per assignment timing, ruby declares the variable in the scope as soon as it sees it, so b will be in the scope but with no value, so present will return false.
You should maybe compared this with defined?
a = "abc"
=> "abc"
defined? a
=> "local-variable"
defined? b
=> nil
b = defined? b
=> "local-variable"