Maintain subclasses of Hash when calling Hash#slice #250
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch corrects i18n's implementation of
Hash#slice
so that it always returns an object of the same class it was originally called on.In the current implementation, it creates a new hash, copies the selected key/value pairs into it, and returns it. This causes the returned value to be a different class, in the case where the original object was a subclass of Hash. This behavior is problematic when using something like
Hashie
orHashWithIndifferentAccess
, because translation string interpolation only works for symbols, and keys can be copied into the new hash as strings, depending on the implementation of the subclass.I discovered this in another library that returns
Hashie::Rash
objects, which work like allow symbol and string key access, but when copied by i18n'sHash#slice
, lose their ability to look up values by symbol keys.