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
Changes to Mash
initialization key string conversion.
#521
Conversation
…ing/symbol keys. Failed examples: rspec ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:33 # Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on method calls rspec ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:37 # Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on explicit operator call rspec ./spec/hashie/extensions/symbolize_keys_spec.rb:98 # Hashie::Extensions::SymbolizeKeys singleton methods .symbolize_keys does not raise error rspec ./spec/hashie/extensions/symbolize_keys_spec.rb:101 # Hashie::Extensions::SymbolizeKeys singleton methods .symbolize_keys produces expected symbolized hash rspec ./spec/hashie/extensions/symbolize_keys_spec.rb:106 # Hashie::Extensions::SymbolizeKeys singleton methods .symbolize_keys! does not raise error rspec ./spec/hashie/extensions/symbolize_keys_spec.rb:109 # Hashie::Extensions::SymbolizeKeys singleton methods .symbolize_keys! produces expected symbolized hash
Failed examples: rspec ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:33 # Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on method calls rspec ./spec/hashie/extensions/mash/symbolize_keys_spec.rb:37 # Hashie::Extensions::Mash::SymbolizeKeys implicit to_hash on double splat is converted on explicit operator call
Failed examples: rspec ./spec/hashie/mash_spec.rb:902 # Hashie::Mash#invert returns a mash with the keys and values inverted rspec ./spec/hashie/mash_spec.rb:982 # Hashie::Mash#dig with numeric key accepts a numeric value as key
81d46af
to
f8a5ac1
Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solid work! Looking forward to this being merged, thanks for hanging in here.
For CHANGELOG, what do you think of "Do not convert keys that cannot be represented as symbols to String in Mash initialization"?
TODO:
- Update README to make this behavior clear.
- Add to UPGRADING.md describing the change(s)
- Bump version
- Fix build (if the current failure is unrelated, make a separate PR first)
@dblock what can be done about this https://travis-ci.org/github/hashie/hashie/jobs/680206889. Not clear for me whats the root of the failure so I can fix it. |
That's this (see above): Fix the CHANGELOG and it will go away and turn green. They both need a period at the end of the line at least. |
This comment has been minimized.
This comment has been minimized.
8175849
to
7782e0c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good with me to merge with a proper UPGRADING entry, please @carolineartz.
@michaelherold Anything from you?
@dblock I didn't do the version bump itself... wasn't sure if this was to be released or if additional changes are going to be added the next release. LMK if i should. |
You should. Bump it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am ready to merge this with version bump. @michaelherold
@@ -1,6 +1,44 @@ | |||
Upgrading Hashie | |||
================ | |||
|
|||
### Upgrading to 5.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether we should do 4.1.0 for this. Some elements of the behavior change, but not major enough for API? @michaelherold what do you prefer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i was wavering on suggesting this...but it is not technically inconsistent with Semver to have entries in changed
that don't correspond with a major version bump?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do I know? :) We've always treated the second digit as "major". We'd be at 24.0 otherwise and that feels like a lot. I'm open to this debate, but for now I say let's do 4.2.0. Will you make this change here @carolineartz, please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually .. re-reading what @michaelherold added to CHANGELOG I'll change my mind. Merging as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Being strict with semver is always hard, especially when folks expect new features in the Major versions. I can agree with the bump to 5.0.0 if we've changed expected behavior in a way that could be breaking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We did. Amen.
Merged. Thanks @carolineartz for hanging in here for a while and making this happen. |
As
Mash
is conceived to provide psuedo-object functionality, handling keys which cannot represent a method call falls outside the scope of provided value.This PR changes the initialization behavior of
Mash
to convert keys to strings only when the key is a candidate for indifferent (string/symbol) access. That is, non-string/symbol keys such as1
,["1"]
{foo: "bar"}
will be left as is.Before this PR, we would see:
After this PR, we see:
Bug Fix
Discussed in issue #516, the changes here address an existing bug where any
Hash
extended withHashie::Extensions::SymbolizeKeys
orMash
extended withHashie::Extensions::Mash::SymbolizeKeys
will throw an error when symbolizing keys if the object has any keys which cannot be converted to symbols, e.g., numeric keys.Given the changes introduced in
Mash
initialization it is now logical that any key which does not respond toto_sym
is preserved in its original type when symbolizing via eitherHashie
extension. This behavior is intended to mirror that ofActiveSupport
's coreHash
extensions[deep]_symbolize_keys[!]
.TODO: