| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
enumerator if called without block
|
| |
|
| |
|
|
|
|
| |
This reverts commit 9c47b874d112414df7f80f9ed852adb48ba6d268.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are (potentially, depending on input) called in several places in
both the router, and Active Record. The code also becomes much cleaner.
This results in ~33% performance gain in both methods.
Calculating -------------------------------------
before 15.696k i/100ms
after 19.865k i/100ms
-------------------------------------------------
before 303.064k (± 2.6%) i/s - 1.523M
after 446.734k (± 2.4%) i/s - 2.245M
On Ruby 2.2, a warning will be emitted about states not being copied,
because we're calling `super` from a subclass. We can safely ignore it,
however, since we're converting the result back into a HWIDA
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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'
```
|
| |
|
|
|
|
| |
All the keys are already Strings by virtue of being a HashWithIndifferentAccess.
|
|
|
|
| |
[fixes #16279]
|
|
|
|
|
| |
Before HashWithIndifferentAccess were doing deep_dup of the inner hashes
when Hash doesn't do. Now both are behaving in the same way.
|
| |
|
|
|
|
|
| |
The phrase "exact copy" in the existing docmentation is somewhat
misleading.
|
|
|
|
|
|
| |
In particular, `.new`, `#update`, `#merge`, `#replace` all accept
objects which respond to `#to_hash`, even if those objects are not
Hashes directly.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
According to our guideline, we leave 1 space between `#` and `=>`, so we
want `# =>` instead of `#=>`.
Thanks to @fxn for the suggestion.
[ci skip]
|
|
|
|
|
| |
Hash#select! returns nil if the hash didn't change and thus behaves differently
from select, so it's return value can't be used as result for the latter.
|
|\
| |
| | |
Change to destructive `deep_symbolize_keys` to avoid a new hash creation.
|
| |
| |
| |
| | |
https://github.com/rails/rails/commit/df24b8790f22384a068fece7042f04ffd2fcb33e which allows to do so. This helps to avoid extra hash object creation, by symbolizing inplace
|
|\ \
| | |
| | | |
HashWithIndifferentAccess#select working as intended
|
| | |
| | |
| | |
| | |
| | |
| | | |
Before this commit, #reject returned a HashWithIndifferentAccess,
whereas #select returned a Hash. Now #select also returns a
HashWithIndifferentAccess.
|
|/ / |
|
|/ |
|
|\
| |
| | |
fix HashWithIndifferentAccess#to_hash behaviour
|
| | |
|
|/
|
|
| |
"There're" => There are for better readability
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a block is passed into the method, it will be invoked for each
duplicated key, with the key in question and the two values as
arguments. The value for the duplicated key in the receiver will
be set to the return value of the block.
This behaviour matches Ruby's long-standing implementation of
Hash#update and is intended to provide a more consistent interface.
HashWithIndifferentAccess#merge is also affected by the change, as it
uses #update internally.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
for nested hashes
|
| |
|
| |
|
|
|
|
| |
Removed some useless docstrings and no-doc'ed some.
|
|
|
|
| |
to return self.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes Hash subclasses convert to HWIA by default for nested
objects of subclasses of Hash, but allows certain subclasses to prevent nested
conversion by introducing Hash#nested_under_indifferent_access that subclasses
can overwrite.
ActiveSupport::OrderedHash is one such subclass that overwrites
+nested_under_indifferent_access+, since implicitly converting it to HWIA would
remove the ordering of keys and values in Ruby 1.8.
This change is necessary because commit ce9456e broke nested indifferent access
conversion for all subclasses of Hash.
|
| |
|