Re: [Rails-core] Bug in HashWithIndifferentAccess?

[Yves-Eric]

I am seeing this with Rails 4.2.4.


On Wednesday, 2 September 2015 05:29:56 UTC+9, James Coleman wrote:
>
> The []= operator should still return whatever it sets, though, which would 
> mean the two different accesses should return the same thing. And I believe 
> this is the case currently. To not do so would be a legitimate bug.
>
> What version of Rails is the example using?
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Bug in HashWithIndifferentAccess?

[Yves-Eric]

Thanks Matt, your analysis is spot on. So the root cause actually a core 
behavior of Ruby. I found this pretty good explanation too on StackOverflow:

http://stackoverflow.com/questions/19033909/why-isnt-method-treated-the-same-as-any-other-method

So, it looks like this cannot be fixed, huh



On Wednesday, 2 September 2015 05:21:38 UTC+9, Matt jones wrote:
>
>
> On Sep 1, 2015, at 6:29 AM, Yves-Eric  
> wrote: 
>
> > Hi all, 
> > 
> > 
> > I think I have stumbled upon a bug in HashWithIndifferentAccess. 
> > I cannot pinpoint it exactly, but I have written a small test case that 
> exhibits the buggy behavior: 
> > 
> > https://gist.github.com/yemartin/54db7476aa41b85e7eb8 
> > 
> > The same code works fine if we use a regular Hash for `@store` instead 
> of a HashWithIndifferentAccess. 
> > Is this a known issue or should I fill a bug report? 
>
> This code in your example: 
>
>   @store[:foo] ||= {bar: 'BAR'} 
>
> does not do what you may be thinking it does. HWIA overrides the `[]=` 
> operator: 
>
>
> https://github.com/rails/rails/blob/master/activesupport/lib/active_support/hash_with_indifferent_access.rb#L96
>  
>
> to convert incoming plain Hash objects into HWIA. So the object that 
> eventually is stored in `@store[:foo]` is NOT the one that was passed to 
> the assignment operator. 
>
> You can check this explicitly: 
>
>
>   require 'active_support/all' 
>
>   @store = ActiveSupport::HashWithIndifferentAccess.new 
>
>   def my_hash 
> @store[:foo] ||= {bar: 'BAR'} 
>   end 
>
>   first_time = my_hash # => {:bar =>”BAR”} 
>   second_time = my_hash # => {“bar”=>”BAR”} 
>
> Note that `first_time` and `second_time` don’t have matching `inspect` 
> results. 
>
> Assignment operators *always* return the value passed on the right-hand 
> side, regardless of what the underlying `[]=` method returns. This means 
> that in cases where the object doesn’t require conversion (coalwater’s 
> modification from your Gist) the object returned from `||=` DOES match, and 
> Waldo is found. 
>
> Not sure if there’s a fix for this - the converting-on-[]= behavior is 
> something many applications are likely to depend on, and the behavior of 
> assignment operators is a core Ruby issue. 
>
> —Matt Jones 
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Bug in HashWithIndifferentAccess?

[James Coleman]

The []= operator should still return whatever it sets, though, which would
mean the two different accesses should return the same thing. And I believe
this is the case currently. To not do so would be a legitimate bug.

What version of Rails is the example using?

On Tue, Sep 1, 2015 at 4:21 PM, Matt Jones  wrote:

>
> On Sep 1, 2015, at 6:29 AM, Yves-Eric  wrote:
>
> > Hi all,
> >
> >
> > I think I have stumbled upon a bug in HashWithIndifferentAccess.
> > I cannot pinpoint it exactly, but I have written a small test case that
> exhibits the buggy behavior:
> >
> > https://gist.github.com/yemartin/54db7476aa41b85e7eb8
> >
> > The same code works fine if we use a regular Hash for `@store` instead
> of a HashWithIndifferentAccess.
> > Is this a known issue or should I fill a bug report?
>
> This code in your example:
>
>   @store[:foo] ||= {bar: 'BAR'}
>
> does not do what you may be thinking it does. HWIA overrides the `[]=`
> operator:
>
>
> https://github.com/rails/rails/blob/master/activesupport/lib/active_support/hash_with_indifferent_access.rb#L96
>
> to convert incoming plain Hash objects into HWIA. So the object that
> eventually is stored in `@store[:foo]` is NOT the one that was passed to
> the assignment operator.
>
> You can check this explicitly:
>
>
>   require 'active_support/all'
>
>   @store = ActiveSupport::HashWithIndifferentAccess.new
>
>   def my_hash
> @store[:foo] ||= {bar: 'BAR'}
>   end
>
>   first_time = my_hash # => {:bar =>”BAR”}
>   second_time = my_hash # => {“bar”=>”BAR”}
>
> Note that `first_time` and `second_time` don’t have matching `inspect`
> results.
>
> Assignment operators *always* return the value passed on the right-hand
> side, regardless of what the underlying `[]=` method returns. This means
> that in cases where the object doesn’t require conversion (coalwater’s
> modification from your Gist) the object returned from `||=` DOES match, and
> Waldo is found.
>
> Not sure if there’s a fix for this - the converting-on-[]= behavior is
> something many applications are likely to depend on, and the behavior of
> assignment operators is a core Ruby issue.
>
> —Matt Jones
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Bug in HashWithIndifferentAccess?

[Matt Jones]

On Sep 1, 2015, at 6:29 AM, Yves-Eric  wrote:

> Hi all,
> 
> 
> I think I have stumbled upon a bug in HashWithIndifferentAccess.
> I cannot pinpoint it exactly, but I have written a small test case that 
> exhibits the buggy behavior:
> 
> https://gist.github.com/yemartin/54db7476aa41b85e7eb8
> 
> The same code works fine if we use a regular Hash for `@store` instead of a 
> HashWithIndifferentAccess.
> Is this a known issue or should I fill a bug report?

This code in your example:

  @store[:foo] ||= {bar: 'BAR'}

does not do what you may be thinking it does. HWIA overrides the `[]=` operator:

https://github.com/rails/rails/blob/master/activesupport/lib/active_support/hash_with_indifferent_access.rb#L96

to convert incoming plain Hash objects into HWIA. So the object that eventually 
is stored in `@store[:foo]` is NOT the one that was passed to the assignment 
operator.

You can check this explicitly:


  require 'active_support/all'

  @store = ActiveSupport::HashWithIndifferentAccess.new

  def my_hash
@store[:foo] ||= {bar: 'BAR'}
  end

  first_time = my_hash # => {:bar =>”BAR”}
  second_time = my_hash # => {“bar”=>”BAR”}

Note that `first_time` and `second_time` don’t have matching `inspect` results. 

Assignment operators *always* return the value passed on the right-hand side, 
regardless of what the underlying `[]=` method returns. This means that in 
cases where the object doesn’t require conversion (coalwater’s modification 
from your Gist) the object returned from `||=` DOES match, and Waldo is found.

Not sure if there’s a fix for this - the converting-on-[]= behavior is 
something many applications are likely to depend on, and the behavior of 
assignment operators is a core Ruby issue.

—Matt Jones

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Rails-core] Bug in HashWithIndifferentAccess?

[James Coleman]

Mohamed,

I don't believe that's correct. And testing it out by replacing the
HashWithIndifferentAccess with a regular Ruby Hash gives the expected
result, so it's definitely different behavior than expected.

That being said, I just tested it on Rails 4.2.3 and it works as expected,
so I'm not sure why Yves is seeing a different result.

On Tue, Sep 1, 2015 at 12:14 PM, Mohamed Wael Khobalatte <
wael.khobala...@gmail.com> wrote:

> You are not storing waldo where you think you are storing it. On first
> access `@store[:foo]` is already initialized, so it does away with your
> waldo assignment, then on second and third access you are populating it.
> `my_hash[:baz]` is `@store[:foo][:baz]`.
>
> On Tue, Sep 1, 2015 at 12:29 PM, Yves-Eric  wrote:
>
>> Hi all,
>>
>>
>> I think I have stumbled upon a bug in HashWithIndifferentAccess.
>> I cannot pinpoint it exactly, but I have written a small test case that
>> exhibits the buggy behavior:
>>
>> https://gist.github.com/yemartin/54db7476aa41b85e7eb8
>>
>> The same code works fine if we use a regular Hash for `@store` instead of
>> a HashWithIndifferentAccess.
>> Is this a known issue or should I fill a bug report?
>>
>>
>> Thank you,
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Wael Khobalatte
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Bug in HashWithIndifferentAccess?

[Yves-Eric]

Hi all,


I think I have stumbled upon a bug in HashWithIndifferentAccess.
I cannot pinpoint it exactly, but I have written a small test case that 
exhibits the buggy behavior:

https://gist.github.com/yemartin/54db7476aa41b85e7eb8

The same code works fine if we use a regular Hash for `@store` instead of a 
HashWithIndifferentAccess.
Is this a known issue or should I fill a bug report?


Thank you,

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Bug in HashWithIndifferentAccess?

[Mohamed Wael Khobalatte]

You are not storing waldo where you think you are storing it. On first
access `@store[:foo]` is already initialized, so it does away with your
waldo assignment, then on second and third access you are populating it.
`my_hash[:baz]` is `@store[:foo][:baz]`.

On Tue, Sep 1, 2015 at 12:29 PM, Yves-Eric  wrote:

> Hi all,
>
>
> I think I have stumbled upon a bug in HashWithIndifferentAccess.
> I cannot pinpoint it exactly, but I have written a small test case that
> exhibits the buggy behavior:
>
> https://gist.github.com/yemartin/54db7476aa41b85e7eb8
>
> The same code works fine if we use a regular Hash for `@store` instead of
> a HashWithIndifferentAccess.
> Is this a known issue or should I fill a bug report?
>
>
> Thank you,
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Wael Khobalatte

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.