I have performed the following test:
irb(main):023:0> a=[]
=> []
irb(main):024:0> b="1"
=> "1"
irb(main):025:0> a.push(b)
=> ["1"]
irb(main):026:0> a
=> ["1"]
irb(main):027:0> b="2"
=> "2"
irb(main):028:0> a
=> ["1"]
So far so good. Now, but as soon as I change b into a hash:
irb(main):012:0> a=[]
=> []
irb(main):013:0> b={}
=> {}
irb(main):014:0> b[:file]="one"
=> "one"
irb(main):015:0> a.push(b)
=> [{:file=>"one"}]
irb(main):016:0> a
=> [{:file=>"one"}]
irb(main):017:0> b[:file]="two"
=> "two"
irb(main):018:0> a
**=> [{:file=>"two"}]**
I didn't even push the b value into the a array. What happened here?
b is not a hash. It is a reference to a hash. And pushing a reference somewhere else won't make it point to a new instance.
Copy your hashes explicitly where you want to, using b.dup.
Sometimes even that might not be enough, as the same applies to values inside a hash: the new hash will have the same references inside, it's a so-called "shallow copy".
(Here I was claiming that strings are immutable in Ruby, but #BroiSatse pointed out that it's not true, and he's right, follow the link in the comments.)
Regardless, the explaination is similar: assignment of a new string into a variable produces a new reference to a string (doesn't mutate existing one), writing a new value into a hash doesn't produce a new hash reference (mutates existing hash instead).
You need to understand how ruby variables and Arrays works. Variable holds a reference to the object, which means that if you do:
a = b = []
Both a and b are referencing exactly some object!
a << 1
b #=> [1]
Array is nothing else but an object which holds many references at the same time. But again, they just reference objects, so if you do:
a = {}
b = [a]
Then b[0] and a variable are referencing to the same object.
a[:foo] = :bar
b #=> [{:foo => :bar}]
Now the reason why it seemed to work differently in your first example is that assignment does not modify the object, but rather changes the reference itself.
a = []
b = '1'
a.push(b)
Now both a[0] and b are pointing to the very same object. However if you do:
b = '2'
You create a new string and changes the reference for variable b, but a[0] is still referencing the old string. However, if instead of changeng the reference you execute some modifying method:
b.replace('2')
You'll see it will give you:
a #=> ['2']
Related
maybe I am used to the initialState from React, but I tried doing something similar in Ruby and I noticed it updates the hash everywhere I initialized it.
Here's an example:
iniatializing_hash = {likes_count: 0, comments_count: 0}
hash_that_uses_initializer = {first: iniatializing_hash, second: iniatializing_hash}
# update first
hash_that_uses_initializer[:first][:likes_count] += 1
hash_that_uses_initializer[:first][:comments_count] += 1
# expect both first and second were updated
puts "first: #{hash_that_uses_initializer[:first].inspect} and second: #{hash_that_uses_initializer[:second].inspect}"
# returns first: {:likes_count=>1, :comments_count=>1} and second: {:likes_count=>1, :comments_count=>1}
I'm guessing this happens because it keeps the connection to the place in memory the hash is loaded.
Is there another elegant way to use an 'initialState' hash in Ruby?
Thanks!
Hashes are passed by reference. When you assign iniatializing_hash, it does not assign a copy of the hash - it assigns a pointer. When you change the values of the hash that you assigned to :first, you're also changing the values of the hash at :second because they're both the same hash.
You can prove they're the same location in memory by calling object_id method on the object:
echo('same hash') if iniatializing_hash.object_id == hash_that_uses_initializer[:first].object_id == hash_that_uses_initializer[:second].object_id
If you want a copy, then you need a deep copy.
def deep_copy(initial_hash)
Marshal.load(Marshal.dump(initial_hash))
end
hash_that_uses_initializer = {first: deep_copy(iniatializing_hash), second: deep_copy(iniatializing_hash)}
Now the hash stored at :first and the :second will be completely different from each other and different from iniatializing_hash
I have a hash like this:
entity = {1=> nil, 2 => {3 => nil, 4 => 1}}
I wrote a function which can remove the null values of the given entity using recursion.
def clear_null_values(entity)
entity.each do |key, value|
if value == nil || value.blank?
entity.delete(key)
elsif value.is_a? Hash
clear_null_values(value)
entity.delete(key) if value.blank?
end
end
end
And also I need the original entity as well for other purposes. So I duplicated the hash variable and then cleared the null values.
final_entity = entity.dup
clear_null_values(entity)
puts entity
puts final_entity
Result:
{2 => {4 => 1}}
{1=> nil, 2 => {4 => 1}} # the nested values are overwritten.
Ideally, the final_entity should be the same as original entity.
Question1: Why is the entity.dup copying only outerhash?
Question2: How to make final_entity the exactly copy of original entity i.e., even if we modify entity then also final_entity shouldn't change?
Try using deep_dup instead, your original code only dup-ed the outermost hash.
final_entity = entity.deep_dup
clear_null_values(entity)
puts entity
puts final_entity
Outputs:
{2=>{4=>1}}
{1=>nil, 2=>{3=>nil, 4=>1}}
Note: Rails also adds Hash#compact, which you could use to simplify clear_null_values.
It would be cleaner, in my opinion, to compute the hash stripped of nil values by operating on entities directly, rather than on a copy of it.
def clear_null_values(entity)
entity.each_with_object({}) do |(k,v),h|
next if v.nil?
h[k] = Hash === v ? clear_null_values(v) : v
end
end
entities = { 1=>nil, 2=>{ 3=>nil, 4=>1 } }
clear_null_values entities
#=> {2=>{4=>1}}
We can confirm entities was not mutated.
entities
#=> {1=>nil, 2=>{3=>nil, 4=>1}}
I have a pluck that is turned into a hash and stored in a variable
#keys_values_hash = Hash[CategoryItemValue.where(category_item_id: #category_item.id).pluck(:key, :value)]
If 2 records have the same :key name then only the most recent record is used and they aren't both added to the hash. But if they have the same value and different keys both are added to the hash.
This also occurs if I swap :key and :value around (.pluck(:value, :key)). If they have now the same value it only uses the most recent one and stores that in the hash. But having the same key is now fine.
I'm not sure of this is being caused by pluck or from being sorted in a hash. I'm leaning towards pluck being the culprit.
What is causing this and how can I stop it from happening. I don't want data being skipped if it has the same key name as another record.
I'm not sure why you need convert pluck result into a Hash, because it was an Array original.
Like you have three CategoryItemValue like below:
id, key, value
1, foo, bar1
2, foo, bar2
3, baz, bar3
when you pluck them directly, you will get a array like:
[ ['foo', 'bar1'], ['foo', 'bar2'], ['baz', 'bar3'] ]
but when you convert it into a hash, you will get:
{'foo' => 'bar2', 'baz' => 'bar3' }
because new hash value will override the old one if key ( foo in the example above) exists.
Or you could try Enumerable#group_by method:
CategoryItemValue.where(...).pluck(:key, :value).group_by { |arr| arr[0] }
I know these are the basics of rails but i still don't know the full difference between = sign and => and the difference between #some_variable, ##some_variable and :some_variable in rails.
Thanks.
OK.
The difference between the = and the => operators is that the first is assignment, the second represents an association in a hash (associative array). So { :key => 'val' } is saying "create an associative array, with :key being the key, and 'val' being the value". If you want to sound like a Rubyist, we call this the "hashrocket". (Believe it or not, this isn't the most strange operator in Ruby; we also have the <=>, or "spaceship operator".)
You may be confused because there is a bit of a shortcut you can use in methods, if the last parameter is a hash, you can omit the squiggly brackets ({}). so calling render :partial => 'foo' is basically calling the render method, passing in a hash with a single key/value pair. Because of this, you often see a hash as the last parameter to sort of have a poor man's optional parameters (you see something similar done in JavaScript too).
In Ruby, any normal word is a local variable. So foo inside a method is a variable scoped to the method level. Prefixing a variable with # means scope the variable to the instance. So #foo in a method is an instance level.
## means a class variable, meaning that ## variables are in scope of the class, and all instances.
: means symbol. A symbol in Ruby is a special kind of string that implies that it will be used as a key. If you are coming from C#/Java, they are similar in use to the key part of an enum. There are some other differences too, but basically any time you are going to treat a string as any sort of key, you use a symbol instead.
Wow, a that's a lot of different concepts together.
1) = is plain old assignment.
a = 4;
puts a
2) => is used to declare hashes
hash = {'a' => 1, 'b' => 2, 'c' => 3}
puts hash['b'] # prints 2
3) #var lets you access object instance variable.
class MyObject
def set_x(x)
#x = x
end
def get_x
#x
end
end
o = MyObject.new
o.set_x 3
puts o.get_x # prints 3
4) ##var lets you access class ('static') variables.
class MyObject
def set_x(x)
##x = x # now you can access '##x' from other MyObject instance
end
def get_x
##x
end
end
o1 = MyObject.new
o1.set_x 3
o2 = MyObject.new
puts o2.get_x # prints 3, even though 'set_x' was invoked on different object
5) I usually think of :var as special 'label' class. Example 2 can be rephrased like this
hash = {:a => 1, :b => 2, :c => 3}
puts hash[:b] # prints 2
I want to define a class method that has access to a local variable. So this would be different for each instance of the class. I know you can make a class method dynamic with lambda like when you use it with named_scope. But can this be done for values that are specific to an instance?
In detail it is the has_attached_file method for the paperclip plugin in rails. I want to pass a lambda for the styles hash so that the image styles can be based off of attributes of the object stored in the DB. Is this possible?
Disclaimer: First, the question (Can you pass self to lambda?) and the problem you're trying to solve (dynamic styles with paperclip) don't fully match up. I won't answer the original question because it's not entirely related to your problem, and rampion took a valiant stab at it.
I'll instead answer your paperclip question.
In detail it is the has_attached_file method for the paperclip plugin in rails. I want to pass a lambda for the styles hash so that the image styles can be based off of attributes of the object stored in the DB. Is this possible?
Yes, it is possible. In paperclip, the :styles option can take a Proc. When the attachment is initialized, if a Proc was used, the attachment itself is passed to the Proc. The attachment has a reference to the associated ActiveRecord object, so you can use that to determine your dynamic styles.
For example, your has_attached_file declaration might look something like this (assuming a User and avatar scenario where the user can customize the size of their avatar):
class User < ActiveRecord::Base
has_attached_file :avatar, :styles => lambda { |attachment|
user = attachment.instance
dimensions = "#{user.avatar_width}x#{user.avatar_height}#"
{ :custom => dimensions }
}
end
Ok, you're being unclear.
Local variables in ruby begin with a lowercase letter (like foo, bar, or steve), and are lexically scoped (like C variables). They have nothing to do with "an instance of a class"
Instance variables in ruby begin with an # sigil (like #foo, #bar, or #carl), and are in scope whenever the current value of self is the object they are stored in.
If you want a method that can access the instance variables of an object directly, that's called an instance method. For example, battle_cry and initialize are both instance methods:
class Character
def initialize(name)
#name=name
end
def battle_cry
#name.upcase + "!!!"
end
def Character.default
new("Leeroy Jenkins")
end
end
A class method, by contrast, is a method for a Class object, and doesn't have access to any of the instance variables of that object. In the above example,
default is a class method.
If you want a (class or instance) method that triggers a change in or gets a value from the current scope, ruby uses a type of callback called a block.
class Character
ATTACKS = [ "Ho!", "Haha!", "Guard!", "Turn!", "Parry!", "Dodge!", "Spin!", "Ha", "THRUST!" ]
def attack
ATTACKS.inject(0) { |dmg, word| dmg + yield(word) }
end
end
person = Character.default
puts person.battle_cry
num_attacks = 0;
damage = person.attack do |saying|
puts saying
num_attacks += 1
rand(3)
end
puts "#{damage} points of damage done in #{num_attacks} attacks"
In the above example, attack uses the yield keyword to call the block passed
to it. When we call attack, then, the local variable num_attacks is still
in scope in the block we pass it (delimited here by do ... end), so we can
increment it. attack is able to pass values into the block, here
they are captured into the saying variable. The block also passes values
back to the method, which show up as the return value of yield.
The word lambda in ruby usually means the lambda keyword, which is used
to make blocks into freestanding, function like objects (which themselves are usually
referred to as lambdas, procs, or Procs).
bounce = lambda { |thing| puts "I'm bouncing a #{thing}" }
bounce["ball"]
bounce["frog"]
So I think what you're asking is whether you can pass a Proc in place of a Hash
for an argument to a method. And the answer is "it depends". If the method only
ever uses the #[] method, then yes:
class Character
attr_accessor :stats
def set_stats(stats)
#stats = stats
end
end
frank = Character.new("Victor Frankenstein")
frank.set_stats({ :str => 7, :dex => 14, :con => 9, :int => 19, :wis => 7, :cha => 11 })
monster = Character.new("Frankenstein's Monster")
monster.set_stats(lambda do |stat_name|
rand(20)
end)
However, it might use some other Hash specific methods, or call the same key multiple times,
which can produce weird results:
monster = Character.new("Frankenstein's Monster")
monster.set_stats(lambda do |stat_name|
rand(20)
end)
monster.stats[:dex] #=> 19
monster.stats[:dex] #=> 1
In which case, you may be better off caching the requests in an intermediate hash. This is fairly easy,
since a Hash can have an initializer block. So if we change the above to:
monster.set_stats(Hash.new do |stats_hash, stat_name|
stats_hash[stat_name] = rand(20)
end)
monster.stats[:dex] #=> 3
monster.stats[:dex] #=> 3
The results are cached in the hash
To see more about Hash block initializers, see ri Hash::new:
-------------------------------------------------------------- Hash::new
Hash.new => hash
Hash.new(obj) => aHash
Hash.new {|hash, key| block } => aHash
------------------------------------------------------------------------
Returns a new, empty hash. If this hash is subsequently accessed
by a key that doesn't correspond to a hash entry, the value
returned depends on the style of new used to create the hash. In
the first form, the access returns nil. If obj is specified, this
single object will be used for all default values. If a block is
specified, it will be called with the hash object and the key, and
should return the default value. It is the block's responsibility
to store the value in the hash if required.
h = Hash.new("Go Fish")
h["a"] = 100
h["b"] = 200
h["a"] #=> 100
h["c"] #=> "Go Fish"
# The following alters the single default object
h["c"].upcase! #=> "GO FISH"
h["d"] #=> "GO FISH"
h.keys #=> ["a", "b"]
# While this creates a new default object each time
h = Hash.new { |hash, key| hash[key] = "Go Fish: #{key}" }
h["c"] #=> "Go Fish: c"
h["c"].upcase! #=> "GO FISH: C"
h["d"] #=> "Go Fish: d"
h.keys #=> ["c", "d"]