| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes #34359
Prior to 5.2.0 (2cad8d7), HashWithIndifferentAccess#to_options acted as
an alias to HashWithIndifferentAccess#symbolize_keys. Now, #to_options
returns an instance of HashWithIndifferentAccess while #symbolize_keys
returns and instance of Hash.
This pr makes it so HashWithIndifferentAccess#to_options acts as an
alias for HashWithIndifferentAccess#symbolize_keys once again.
|
| | |
|
| |
|
|
| |
Follow up of #32605.
|
| |
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
| |
|
|
| |
See https://github.com/ruby/ruby/blob/ruby_2_3/NEWS
|
| | |
|
| |
|
|
|
|
|
| |
Make sure that when transforming the keys of a HashWithIndifferentAccess
we can still access with indifferent access in Ruby 2.5.
Closes #32007.
|
| |
|
|
| |
Follow up of #30728.
|
| |
|
|
|
|
|
|
|
|
|
| |
`HashWithIndifferentAccess`
Currently, `#transform_values`, `#select` and `#reject` return instance
of `HashWithIndifferentAccess`. But `#transform_keys` returns instance
of Hash. This behavior is a bit confusing.
I think that `HashWithIndifferentAccess#transform_keys` should also return
instance of `HashWithIndifferentAccess` as well as other methods.
|
| |
|
|
| |
Signed-off-by: Yuki Nishijima <yk.nishijima@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
The implementation of HashWithIndifferentAccess#default didn't
distinguish `default` from `default(nil)`, which caused an incorrect
result for `default` if `nil` was used as a key.
Define HashWithIndifferentAccess#dig so that hackery that behaves
differently from Hash#default can be removed from
HashWithIndifferentAccess#default.
|
| | |
|
| | |
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| |
|
|
|
|
|
| |
`fetch_values` was added to Hash in Ruby 2.3.0:
https://bugs.ruby-lang.org/issues/10017
This patch adds an implemention for instances of HWAI, in line
with the existing definitions of `fetch` and `values_at`.
|
| |
|
|
|
|
| |
HashWithIndifferentAccessTest::HashWithIndifferentAccess`
Caused since #28607.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
tests
- Fixed the wrong use of with_indifferent_access on hash in the test which failed for isolated tests
- Renamed to appropriately specify what the test does
|
| | |
|
|
|
Hashes with indifferent access should support `reverse_merge` out-of-the-box
but they don't; for instance the following code fails:
```ruby
require 'active_support'
require 'active_support/hash_with_indifferent_access'
hash = HashWithIndifferentAccess.new key: :old_value
hash.reverse_merge key: :new_value
```
This PR fixes the case above by simply requiring
`active_support/core_ext/hash/reverse_merge` in `hash_with_indifferent_access.rb`
and adding a test that confirms the fix.
---
Here are more details about the bugfix.
Currently, `reverse_merge` is [defined in HashWithIndifferentAccess](https://github.com/rails/rails/blob/4e8ea13ba1a0870905a46fac5f232d9f41eef8a4/activesupport/lib/active_support/hash_with_indifferent_access.rb#L208)
by invoking `super`, that is by invoking `Hash#reverse_merge`:
```ruby
def reverse_merge(other_hash)
super(self.class.new_from_hash_copying_default(other_hash))
end
```
However, Ruby's `Hash` does not have the `reverse_merge` by default: it must be
added by ActiveSupport, and that requires the following line of code to be
present:
```ruby
require 'active_support/core_ext/hash/reverse_merge'
```
|
