| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to how we have implemented the bang/underbang/query behavior within
Mash, setting keys that have those affixes in them actually allow
overwriting the behavior of those affixes. As such, we shouldn't warn
when setting a key that matches those patterns.
When it comes to setter-like keys, I believe we still _do_ want to warn
for two reasons:
1. Trying to access the key via method access is a syntax error. Ruby
expects any method ending in `=` to be a 2+-arity method due to the
infix notation of setter methods. This is unexpected behavior unless
you're very familiar with Ruby parsing.
2. You can still retrieve the key via the normal `Hash#[]` reader, but
it prevents setting a similar key without the equal sign. You can see
this in the test about setters. I'd say that is unexpected and
surprising behavior.
Because of these two gotchas, I think we should still warn in cases
where you try to set a key that looks like a setter.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In order for `#dig` to work properly, we need Arrays to be
`Hashie::Array`s to be aware of the key conversion. Our original
`Mash#convert_value` method was deconverting `Hashie::Array`s into
normal Arrays and causing `#dig` to behave in an unexpected manner.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Update github urls to hashie/hashie
* Point omniauth in integration tests at master.
Until omniauth releases the changes merged from
https://github.com/omniauth/omniauth/pull/977 , we must point at
master branch.
* revert incorrect change of gem email
Co-Authored-By: Michael Herold <github@michaeljherold.com>
* Reference open issue for release
|
| |\
| |
| | |
Remove references to blacklists and whitelists
|
| | | |
|
| |/
|
|
|
| |
For accessibility reasons, we should limit our lines to 100 chars max.
https://github.com/slack-ruby/slack-ruby-client/pull/293#discussion_r309472083
|
| | |
|
| |
|
|
|
|
| |
As of ruby 2.6, Hash#merge and Hash#merge! allow for multiple hashes
to be passed to the method, and will merge each one in the order that
they were passed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling the following non-destructive hash methods:
:compact
:invert
:reject
:select
:slice
:transform_keys
:transform_values
we would be returned an instance of a standard Hash rather
than a Mash (or subclass). This changes that behavior to
instead return an instance of the class the method was
called on.
|
| |
|
|
|
|
|
|
|
|
|
| |
In some cases, you want to be able to ignore Mash warnings for keys
that you know you aren't going to access via a method accessor, yet be
warned for other keys that you know you might want to access. This
change adds the ability to selectively ignore warnings for specific keys
instead of globally ignoring the warnings.
The change retains the original behavior as well, so if you call
`Mash.disable_warnings` without a value it will still globally ignore
the warnings.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Mash.load` uses the Ruby standard library to load Yaml-serialized files
into a Mash. The original implementation used `YAML.load` for this
purpose. However, that method is inherently unsafe so we switched to
using `YAML.safe_load`.
Safely loading Yaml files has many different domain-specific
configuration flags that we did not, by default, expose. This change
introduces the ability to configure the safe loading of Yaml files so
that all types of Yaml can be loaded when necessary using the flags from
the standard library.
This implementation preserves the backwards-compatibility with the prior
implementation so that it should not require updates from users of the
current `Mash.load` behavior. For those who this change affects, we
included upgrading documentation to ease the transition.
|
| |
|
|
| |
Refs: https://github.com/intridea/hashie/issues/464
|
| |
|
|
|
|
|
|
|
|
|
| |
Disable Metrics/BlockLength in specs because the length of a block in
the test suite isn't something we want to lint. We want the tests to be
as long as they need to be.
Set an explicit line length metric instead of continually updating this
as we go. Let's pick a max line length that we want to see and stick
with it. This metric should only ever decrease: we don't want to see it
ever increase again.
|
| |
|
|
|
| |
Also, reorganize the test into the existing file and update the
changelog.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big step forward in our Rubocop setup. I addressed all of the todos
from the current version of Rubocop that made sense to. The only things that
remain are metrics and one cop that relies on the line length metric to work.
I made some judgment calls on disabling a few cops:
1. The `Layout/IndentHeredoc` cop wants you to either use the squiggly heredoc
from Ruby 2.3 or introduce a library. Since we are a low-level library that
is used as a transitive dependency, we cannot introduce another library as a
dependence, so that option is out. Also, we support Rubies back to 2.0
currently, so using the squiggly heredoc isn't an option. Once we remove
support for Rubies older than 2.3, we can switch to the squiggly heredoc cop.
2. The `Naming/FileName` cop was reporting false positives for a few files in
the repository, so I disabled it on those files.
3. The `Style/DoubleNegation` cop reports lints on a few cases where we use
double negation. Given the very generic nature of Hashie, the double-negation
is the easiest, clearest way to express that we want an item to be a Boolean.
I disabled the cop because we exist in the gray area where this makes sense.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case where you want to set deeply nested values through chained calls to
the `#[]` method or through method accessors (without using the bang methods),
you might set a `default_proc` on a Mash that recursively creates the key as you
access it. Previously, the `default_proc` was not being propagated down to
sub-Hashes because the way that `#dup` was written wasn't passing the
`default_proc` do the duplicated object.
Now, the `default_proc` is correctly being sent to the duplicated object, which
allows this pattern to work:
```ruby
h = Hashie::Mash.new { |mash, key| mash[key] = mash.class.new(&mash.default_proc) }
h.a.b.c = :xyz
h[:a][:b][:c] #=> :xyz
h[:x][:y][:z] = :abc
h.x.y.z #=> :abc
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we switched to using `#respond_to?` to detecting whether to log
a Mash collision, we started reporting when we were overwriting keys
that already exist in the Mash. This is a poor experience because it
causes extra warnings (as in #414) or, in the worst case, causes an
"undefined method" error (as in #413).
This change fixes that problem and benchmarks to ensure we're not
appreciably regressing performance. The results of two benchmarks are
below:
```
bundle exec ruby benchmark/mash_method_access.rb:
Warming up --------------------------------------
before 92.456k i/100ms
Calculating -------------------------------------
before 1.290M (± 4.4%) i/s - 6.472M in 5.028183s
Pausing here -- run Ruby again to measure the next benchmark...
Warming up --------------------------------------
after 92.941k i/100ms
Calculating -------------------------------------
after 1.326M (± 5.4%) i/s - 6.692M in 5.060756s
Comparison:
after: 1326239.2 i/s
before: 1289624.0 i/s - same-ish: difference falls within error
```
and
```
within spec/integrations/omniauth,
bundle exec rake perf:ips
Warming up --------------------------------------
before 1.260k i/100ms
Calculating -------------------------------------
before 13.114k (± 4.2%) i/s - 66.780k in 5.101689s
Pausing here -- run Ruby again to measure the next benchmark...
Warming up --------------------------------------
after 1.299k i/100ms
Calculating -------------------------------------
after 13.149k (± 4.0%) i/s - 66.249k in 5.046630s
Comparison:
after: 13148.9 i/s
before: 13113.8 i/s - same-ish: difference falls within error
```
Closes #413
Closes #414
|
| | |
|
| |
|
|
| |
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
```
|
| |
|
|
| |
Correct usage of a shared_context is to use include_context
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
- a one liner with no complexity for pending specs by Ruby Engine / Version
- removes all complexity from Hashie
|
| |
|
|
| |
- Better paradigm for pending specs due to bugs in interpreter
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a way to handle the broken spec in MRI 2.2.x that was
introduced by a regression in the language. It is slated to be in 2.3.0
and seems partially fixed in 2.2.2.
In order to have the full spec suite run on every version of Ruby but
keep the brevity of the Mash specs, we needed a way to check for the
Ruby version and selectively disable the two errant specs.
We need to be testing on the latest Ruby, so this seems to be the best
compromise.
For more information on the breakage in Ruby, see [issue 285][rubybug].
For more information on this decision, see [issue 294][workaround].
Fixes #294
/cc #285
[rubybug]: https://github.com/intridea/hashie/pull/285
[workaround]: https://github.com/intridea/hashie/pull/294
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes intridea/hashie#270
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See discussion at https://github.com/intridea/hashie/pull/197
|
| |
|
|
|
|
|
| |
This reverts commit 33f73e0635fc4d2c9f4726c744b50667c82d7b39.
Conflicts:
CHANGELOG.md
|
| | |
|
| | |
|
| |
|
|
|
| |
This method now converts the keys before trying to access them from the
Mash.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Strong Parameters.
|
| | |
|
