| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds an extension for Mash that makes it behave like
`OpenStruct`. It reduces overhead of `method_missing?` magic which is a
good thing! It's inspired by the recent @sferik's work on `OpenStruct` —
https://github.com/ruby/ruby/pull/1033.
When using it in `Mash` subclasses it makes them *remember* methods so
then it's more like `ActiveModel` than `OpenStruct` in this case.
To use it like `OpenStruct` one could use this shortcut:
```ruby
{ foo: 1, bar: 2 }.to_mash.with_accessors!
```
Implementation details:
It injects to class an anonymous module that stores accessor method
definitions. This is inspired by `ActiveModel` / `ActiveRecord`. It
allows to override accessors in subclass and call them via `super` if
this is intended.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Trash should be able to copy properties from other properties without
causing a problem. Trash should also, when doing this, not set any
properties that it doesn't define.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hashie::Extensions::Parsers::YamlErbParser::Pathname)
`Hashie::Mash.load` require `Pathname` since v3.4.5.
see: bbafaded9d
```
irb(main):001:0> require "hashie"
=> true
irb(main):002:0> Hashie::Mash.load("foo.yml")
Traceback (most recent call last):
6: from /opt/rubies/2.6.0-dev/bin/irb:11:in `<main>'
5: from (irb):2
4: from /Users/onaka/.gem/ruby/2.6.0/gems/hashie-3.5.7/lib/hashie/mash.rb:105:in `load'
3: from /Users/onaka/.gem/ruby/2.6.0/gems/hashie-3.5.7/lib/hashie/extensions/parsers/yaml_erb_parser.rb:19:in `perform'
2: from /Users/onaka/.gem/ruby/2.6.0/gems/hashie-3.5.7/lib/hashie/extensions/parsers/yaml_erb_parser.rb:19:in `new'
1: from /Users/onaka/.gem/ruby/2.6.0/gems/hashie-3.5.7/lib/hashie/extensions/parsers/yaml_erb_parser.rb:9:in `initialize'
NameError (uninitialized constant Hashie::Extensions::Parsers::YamlErbParser::Pathname)
irb(main):003:0> require "pathname"
=> true
irb(main):004:0> Hashie::Mash.load("foo.yml")
=> #<Hashie::Mash bar="baz">
```
|
| |\
| |
| | |
Add an integration spec for Elasticsearch
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Elasticsearch gems heavily integrate with Hashie. This leads people to want
to use a Mash as the backer for an Elasticsearch model, but the behavior is
different than they expect. By having this integration spec, we're covering two
things:
1. It might help ensure that we don't break the Elasticsearch ecosystem with
changes in Hashie as has happened in the past.
2. It communicates some gotchas that happen with using a Mash as the backer for
an Elasticsearch model.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Definition: Codependent properties
A set of two or more properties who have "required" validations that are based
on each other.
Example:
```ruby
class OneOrMore < Hashie::Dash
property :a, required: -> { b.nil? }
property :b, required: -> { a.nil? }
end
```
When constructing a Dash via the merge initializer, codependent properties have
their "required" validation run too early when their values are set to `nil`,
which causes an `ArgumentError` to be raised in the case that the first property
is set to `nil`.
This is an order-dependence bug that is fixed by this commit. By pruning off
`nil` values only during initialization via the merge initializer, we can
prevent this problem from occurring for the case of `nil` values.
However, this is an indication of a larger problem with the architecture of
Dash. We should be setting all the properties before running the validations.
Rearchitecting this will be quite an undertaking.
|
| |
|
|
|
|
|
|
| |
During non-destructive merges (i.e. `#merge`), the `IndifferentAccess` mixin was
failing to inject itself into the resulting Hash. This caused a `NoMethodError`
to be thrown when attempting to perform the action.
Now, we properly inject the mixin when necessary so the `#merge` method works.
|
| |\
| |
| | |
Propagate Mash `default_proc` to sub-Hashes
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
```
|
| |/
|
|
|
|
|
|
|
| |
The behavior of Mash subclasses around the wrapping of inner sub-Hashes can be
confusing, so we should have some documentation around it. This captures the
process of subclasses wrapping their sub-Hashes in a guided fashion.
Also, this reorganizes a bit of the Mash readme to group related topics together
under headlines.
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Removed _Your contribution here._ in entry for release 3.5.6.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
When running rspec specs on the ruby-grape project with warnings enabled
this warning is printed hundreds of times.
This change fixes the warning.
Also, turn on warnings when running rspec to see when this happens.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the behaviors of Mash that we see regularly surprise users is
that Mash stringifies any keys passed into it. This leads to unexpected
lack of synergy between Mash and its cousins (particularly Dash), since
the property DSLs do not handle indifferent key access.
This extension ensures that the original keys are kept inside the Mash's
data structure, at the expense of more costly logic for fetching
information indifferently. I have included a benchmark that compares the
two. The benchmark shows that when you are passing string keys into a
Mash, using this extension will actually be _faster_ than the default
implementation, but that the reverse is true when passing symbol keys.
In #296, I tried to do this universally for all Mashes, which slowed
down the fetching behavior for Mash significantly. I like this attempt
much better because it allows users to opt into the new behavior if they
want it, while still keeping the default implementation as-is.
Fixes #196 by giving the option of keeping the original structure of the
Mash when using it with Dash.
Fixes #246 by giving the option of opting into keeping the original
keys.
Closes #296 by giving a more flexible path forward that doesn't change
the semantics of the main Mash class.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We often have requests to make Mash symbolize keys by default. Since
Hashie is used across so many different version of Ruby, we have been
hesitant to make this behavior the default. However, there are valid use
cases for wanting symbol keys.
To satisfy both the needs of those on older Rubies and the needs of
those who want symbol keys, this extension gives the end-user the
ability to toggle on symbolized keys in their Mash subclasses. By adding
this ability, we can wait to implement the symbol keys as a default for
a while longer.
See #341, #342 for more information. This is a half-measure toward the
implementation of #342 (which makes Mash symbolize keys by default).
|
| |
|
|
|
|
|
| |
By switching to `#respond_to?` we make the lookup of method collisions
a lot faster while retaining the ability to report on them.
Closes #410
|
| |
|
|
|
|
|
|
| |
In some circumstances when a project has the Rails constant defined we
may still not be able to require the rails/railtie dependency. Before this
change this would raise an exception. This change seeks to add better
detection of the railtie dependency and add logging that this dependency
is missing but still allow execution to continue.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
With a test that would fail without this patch.
|
| |\
| |
| | |
Allow Mash subclasses to disable warnings
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
```
|
| |\ \
| |/
|/| |
Bring integration tests into main test harness
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have a nice integration spec harness, so let's make sure we use it
when we're working on the gem. I'm making the following changes:
* Make `bundle exec rake` run integration specs, except on Travis.
* Silence a warning in the OmniAuth integration spec that has nothing to
do with Hashie.
* Make Guard run integration specs when appropriate. Now, when you run
all tasks you will run integration specs. Also, if you modify an
integration spec, it will run. Lastly, if you modify anything in `lib`
the integration specs will run.
* Keeps the extra Travis build that only runs integration specs. Travis
didn't like the Rake task that included it and there's extra signal by
doing it this way anyway.
|
