| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The auto-load is never triggered because there is no `Hashie::Logger`
constant to trigger it. We need to `require` the file in the top level
`hashie.rb` and anywhere else that uses it (in case someone just loads a
single file).
At the moment, this is only used in Mash, so we're covered.
|
| |
|
|
| |
With a test that would fail without this patch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we are transitively used as a dependency in many projects, we
should have given the ability to toggle this behavior off. The logging
feature is more of a "help people get started with Mash" feature. If
you're using Hashie in a library, it's likely that you already know the
tradeoffs of attempting to override methods on the object.
To use this feature, you only have to subclass Mash and then call the
class method:
```ruby
class KeyStore < Hashie::Mash
disable_warnings
end
```
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
IgnoreUndeclared
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #367
While it's probably not something hashie wants to allow, previously
this was possible so we shouldn't break this when going 3.4.4 to 3.4.5.
As an example, omniauth requires hashie/mash alone:
https://github.com/omniauth/omniauth/blob/d941c4bcb1eb52f3674dd46225808751dd6a1c2f/lib/omniauth/auth_hash.rb#L1
This appears to have been broken in #358.
Note, we can't write a test for this because we require 'hashie' in the spec_helper
which properly defines the Hashie::Extensions::Array constant and autoloads
the pretty_inspect here:
https://github.com/intridea/hashie/blob/229ee36d7c6a07eff6d8a0434726e12b8c3a0223/lib/hashie.rb#L48
**Before**
```
10:44:30 ~/Code/hashie (master) (2.3.1) + be irb
irb(main):001:0> require 'hashie/mash'
NameError: uninitialized constant Hashie::Extensions::Array
Did you mean? Hashie::Array
Array
from /Users/joerafaniello/Code/hashie/lib/hashie/array.rb:3:in `<class:Array>'
from /Users/joerafaniello/Code/hashie/lib/hashie/array.rb:2:in `<module:Hashie>'
from /Users/joerafaniello/Code/hashie/lib/hashie/array.rb:1:in `<top (required)>'
from /Users/joerafaniello/Code/hashie/lib/hashie/mash.rb:2:in `require'
from /Users/joerafaniello/Code/hashie/lib/hashie/mash.rb:2:in `<top (required)>'
...
```
**After**
```
10:44:40 ~/Code/hashie (master) (2.3.1) + be irb
irb(main):001:0> require 'hashie/mash'
=> true
irb(main):002:0> exit
```
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
(#365)
* Checking for explicit definition of ActiveSupport::HashWithIndifferentAccess, current code assumes that the presence of ActiveSupport implies that HashWithIndifferentAccess was required
* Correcting typo in CHANGELOG update
* Updating CHANGELOG to log fix to #deep_locate
|
| |
|
|
| |
https://github.com/intridea/hashie/issues/331
|
| | |
|
| | |
|
| |\
| |
| | |
Stringified translations wasn't working in IgnoreUndeclared.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Translation from `:symbol` and translation from `'string'` are
different translations. No need in coercion to symbol or some other
coercions.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
`HashWithDifferentAccess` wasn't properly setting the indifferent
access when merging in other hashes. This reruns `#convert!` after
calling the superclass implementation of the method, so it preserves
indifferent access on the resulting object.
Fixes #345
|
| | |
|
| |
|
|
|
|
|
|
| |
Added inheritance
Added multiple bang notation merging
Minor performace improvements - ends_with? is faster than regexp
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Hashie::Extensions::DeepLocate.deep_locate`, when passed a key, did not
take into account indifferent access. This lead to a regression in
v3.4.1 when `Hashie::Extensions::DeepFind` was modified to be backed by
`DeepLocate`.
This change makes the default comparator aware of indifferent access by
inspecting the object that it is called on. It works with both
`ActiveSupport::HashWithIndifferentAccess` and
`Hashie::Extensions::IndifferentAccess`.
Fixes #309
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation about the MethodQuery module spells out the expected
behavior. While the spec suite appeared to be testing the same, the
RSpec matchers were not actually checking the behavior properly. This
lead to a divergence between the expected behavior, as outlined in the
module documentation, and the actual behavior, as tested in the spec
suite.
This is the reason that #299 is happening: the expected behavior is not
the actual behavior. I have included a test for #299 to show that it
works as expected in this branch.
This change makes the spec suite match the behavior in the module
documentation, then modifies the methods to match the documentated
specification.
Lastly, I took the time to clean up the MethodQuery module for two
reasons:
1. The old implementation used Regexps on the stringified
method names, which is unnecessary since we have the wonderful
`String#end_with?` method to check the suffix of a strings.
2. The old logic was difficult to reason through, so I clarified the
intent of the methods by reducing the complexity of the conditionals
and extracting meaningful methods where possible.
|
| | |
|
| |
|
|
|
|
|
| |
Extension
- Updated, and enhanced specs
- Improved documentation
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
accessed that does not exist in the hash.
In Python a "Hash" is called a "Dictionary", and ...
> "It is an error to extract a value using a non-existent key."
See: https://docs.python.org/2/tutorial/datastructures.html#dictionaries
EXAMPLE:
class StrictHash < Hash
include Hashie::Extensions::StrictKeyAccess
end
>> hash = StrictHash[foo: "bar"]
=> {:foo=>"bar"}
>> hash[:foo]
=> "bar"
>> hash[:cow]
KeyError: key not found: :cow
|
| |\
| |
| | |
Refactor `Hashie::Extensions::Coercion`, add cache.
|
| | | |
|
| |/ |
|
| |\
| |
| | |
Some micro optimizations to Hashie::Mash.
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
extended singleton objects.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #188 brought up the fact that a Trash is really just a Dash with
some extended behavior. Why don't we make that a little more explicit
and define its behavior as an extension?
*Follow Up*
If this is merged, I move that we deprecate Trash for removal in 4.0.
I think reducing the number of classes will help users better understand
what behavior they are including in their subclasses.
In the long run, a 4.0 release would look really good with all of the behavior
factored out into extension methods. As we continue down that path, we can
slowly deprecate all of the `*ash` classes with the 3.x releases.
What do the other maintainers think of this suggestion?
Fixes #188
|
| |
|
|
| |
Fixes #284
|
| |
|
|
|
|
|
|
|
|
| |
Ruby 1.8.7 had Object#id and #type, both of which were deprecated,
which Hashie::Mash wanted to cover with more reasonable methods.
These methods in Object were removed in ruby 1.9. The cover methods
are unneeded, and can cause problems with Mash::SafeAssignment
preventing you from using these as keys.
Fixes #290
|
