-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested keys trigger conflict warning #432
Comments
That definitely looks like a bug. Care to write a spec and maybe even a fix? |
This isn't a bug, surprisingly, but it is definitely unexpected behavior. The way Mashes propagate themselves inside of nested hashes involves wrapping the included hashes inside the Mash class. When you subclass a Mash, instead of wrapping the included hashes in a Mash, it wraps it in itself (in this case a Since I'm not sure what would be more surprising - if the inner hash was a Mash, or if the inner hash is a Foo. What do you think? |
Mash keeps on giving. Maybe someone can update http://code.dblock.org/2017/02/24/the-demonic-possession-of-hashie-mash.html for me? No but really, please. I think Mash should propagate all behavior except when otherwise. Frankly this is an amazing side effect - sometimes we want functions to propagate, sometimes not. I want it both ways :) |
I would see if wrapping the inside of the Mash in a |
This change: diff --git a/lib/hashie/mash.rb b/lib/hashie/mash.rb
index a6d1347..a5d3900 100644
--- a/lib/hashie/mash.rb
+++ b/lib/hashie/mash.rb
@@ -324,7 +324,7 @@ module Hashie
duping ? val.dup : val
when ::Hash
val = val.dup if duping
- self.class.new(val)
+ Mash.new(val)
when Array
val.map { |e| convert_value(e) }
when ::Array causes these failures:
This is because the class that uses the Mash extension loses the extension when we cast it back to a Mash via the change. Since that's the case, making the change would require a major version bump. I'm not sure I want to do that right now - I would rather save the bump to 4.0 for more changes than this little one. What do you think, dB? If this is a change we want to make, we could start a 4.0 branch and make it on there ... and if we make the change, I think we need to work out a way to not drop any Mash extensions that are included on the class. The more I think about it, the more I think that this is probably intended behavior and not a bug, in particular because of the existence of Mash extensions. At any rate, @rpdillon, if you would like to suppress the warning, you can do this: class Foo < Hashie::Mash
disable_warnings
def bar
self.baz
end
end |
I think we should leave things as is and document the behavior of inheriting the class itself for nested mashes. We can also create a class called |
Given the following class:
I'm finding that
Foo.new(baz: 1)
generates no warnings, as expectedFoo.new(bar: 1)
generates warnings, as expectedFoo.new(baz: { bar: 1 })
generates warnings, which is not expectedThe final example gives this warning:
Is this behavior intended?
The text was updated successfully, but these errors were encountered: