| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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.
|
|
|
|
| |
This basically reverts 8da30ad6be34339124ba4cb4e36aea260dda12bc
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
|
|
|
| |
It was right as originally written in #15440.
|
|\
| |
| | |
Fix HashWithIndifferentAccess#default when include?(nil)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
`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`.
|
| |
| |
| |
| |
| |
| | |
In the context of controller parameters, reverse_merge is commonly used
to provide defaults for user input. Having an alias to reverse_merge
called with_defaults feels more idiomatic for Rails.
|
|/ |
|
|
|
|
|
|
|
| |
Since using a `ActiveSupport::Deprecation::DeprecatedConstantProxy`
would prevent people from inheriting this class and extending it
from the `ActiveSupport::HashWithIndifferentAccess` one would break
the ancestors chain, that's the best option we have here.
|
| |
|
|
|
|
|
|
|
|
|
| |
Pointed out by @matthewd that the HWIA subclass changes the
AS scoped class and top-level HWIA hierarchies out from under
existing classes.
This reverts commit 71da39097b67114329be6d8db7fe6911124531af, reversing
changes made to 41c33bd4b2ec3f4a482e6030b6fda15091d81e4a.
|
|
|
|
|
|
|
|
|
| |
This constant was kept for the sake of backward compatibility; it
is still available under `ActiveSupport::HashWithIndifferentAccess`.
Furthermore, since Ruby 2.5 (https://bugs.ruby-lang.org/issues/11547)
won't support top level constant lookup, people would have to update
their code anyway.
|
|
|
|
|
|
|
|
| |
`Hash#compact` of Ruby native returns new hash.
Therefore, in order to return HWIDA as in the past version, need to
define own `#compact` to HWIDA.
Related: #26868
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
On Ruby 2.4, naitive `Hash#transform_values` is implemented.
`Hash#transform_values` uses an instance of Hash (`rb_hash_new`) to
collect returned values of a block.
For ensuring `#transform_values` of HWIDA to return HWIDA, we should
define `#transform_values` on HWIDA.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a01cf703 as explained in the comment to #26826:
Realized that this PR caused the following warning in Travis CI:
```
/home/travis/build/rails/rails/activesupport/lib/active_support/dependencies.rb:293: warning: loading in progress, circular require considered harmful - /home/travis/build/rails/rails/activesupport/lib/active_support/core_ext/hash/indifferent_access.rb
```
Indeed, `active_support/core_ext/hash/indifferent_access.rb` **needs** to require `active_support/hash_with_indifferent_access.rb` in order to access the class `ActiveSupport::HashWithIndifferentAccess`.
The other way around, though, is not _strictly_ required, unless someone tries (like I did in the [gist above](https://gist.github.com/claudiob/43cc7fe77ff95951538af2825a71e5ec)) to use `ActiveSupport::HashWithIndifferentAccess` by only requiring `active_support/hash_with_indifferent_access.rb` without first requiring `active_support/core_ext/hash/indifferent_access.rb`.
I think the solution to this is to revert this PR and instead change the documentation to explicitly state that **developers should not require 'active_support/hash_with_indifferent_access'** if all they want is to use `ActiveSupport::HashWithIndifferentAccess` – instead they should require `active_support/core_ext/hash/indifferent_access.rb`.
|
| |
|
|
|
|
|
|
|
|
|
| |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
| |
|
|
|
|
| |
This method was already niche, and is now redundant with `.new`
|
|\
| |
| |
| |
| | |
`HashWithIndifferentAccess.new` respects the default value or proc on
objects that respond to `#to_hash`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
objects that respond to `#to_hash`.
Builds on the work of #12550 where `.new` will convert the object (that respond to `#to_hash`) to a hash and
add that hash's keys and values to itself.
This change will also make `.new` respect the default value or proc of objects that respond to `#to_hash`.
In other words, this `.new` behaves exactly like `.new_from_hash_copying_default`.
`.new_from_hash_copying_default` now simply invokes `.new` and any references to `.new_from_hash_copying_default`
are replaced with `.new`.
Added tests confirm behavior.
|
| | |
|
| |
| |
| |
| | |
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.
|
| |
|