Permalink
Commits on Feb 22, 2018
  1. Merge pull request #441 from nicolasleger/patch-1

    dblock committed Feb 22, 2018
    [CI] Test against Ruby 2.5
Commits on Feb 8, 2018
  1. Merge pull request #438 from onk/require_pathname

    michaelherold committed Feb 8, 2018
    Fix: NameError (uninitialized constant Hashie::Extensions::Parsers::YamlErbParser::Pathname)
  2. Fix: NameError (uninitialized constant Hashie::Extensions::Parsers::Y…

    onk committed Feb 6, 2018
    …amlErbParser::Pathname)
    
    `Hashie::Mash.load` require `Pathname` since v3.4.5.
    
    see: bbafade
    
    ```
    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">
    ```
Commits on Feb 7, 2018
  1. Merge pull request #440 from michaelherold/document-dash-splat

    dblock committed Feb 7, 2018
    Document Dash double-splat operator gotchas
  2. Merge pull request #439 from michaelherold/elasticsearch-integration

    dblock committed Feb 7, 2018
    Add an integration spec for Elasticsearch
  3. Merge pull request #437 from michaelherold/codependent-properties

    dblock committed Feb 7, 2018
    Allow codependent Dash attributes to initialize
  4. Document Dash double-splat operator gotchas

    michaelherold committed Feb 7, 2018
    Let this be a lesson, folks: don't subclass the Hash class!
    
    For more information, see the following:
    #353 (comment)
  5. Add an integration spec for Elasticsearch

    michaelherold committed Feb 7, 2018
    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.
  6. Allow codependent Dash attributes to initialize

    michaelherold committed Feb 6, 2018
    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.
Commits on Feb 5, 2018
  1. Merge pull request #436 from michaelherold/ensure-indifferent-access-…

    michaelherold committed Feb 5, 2018
    …after-merge
    
    Ensure IndifferentAccess is injected after merge
  2. Ensure IndifferentAccess is injected after merge

    michaelherold committed Feb 4, 2018
    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.
  3. Merge pull request #435 from michaelherold/fix-default-proc-storage

    dblock committed Feb 5, 2018
    Propagate Mash `default_proc` to sub-Hashes
  4. Merge pull request #434 from michaelherold/add-docs-around-mash-subcl…

    dblock committed Feb 5, 2018
    …asses
    
    Add documentation for Mash subclasses
Commits on Feb 4, 2018
  1. Propagate Mash `default_proc` to sub-Hashes

    michaelherold committed Feb 4, 2018
    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
    ```
  2. Add documentation for Mash subclasses

    michaelherold committed Feb 4, 2018
    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.
Commits on Dec 19, 2017
Commits on Nov 13, 2017
  1. Removed boilerplate text from changelog for 3.5.6 (#426)

    skoolstra authored and michaelherold committed Nov 13, 2017
    Removed _Your contribution here._ in entry for release 3.5.6.
Commits on Nov 4, 2017
  1. Update rubies in CI (#425)

    kachick authored and dblock committed Nov 4, 2017
Commits on Aug 2, 2017
  1. Merge pull request #422 from gilesbowkett/typo-fix

    dblock committed Aug 2, 2017
    removed typo in error message
Commits on Aug 1, 2017
Commits on Jul 12, 2017
Commits on Mar 1, 2017
  1. Fix "@disable_warnings" spec warning (#416)

    axfcampos authored and michaelherold committed Mar 1, 2017
    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.
Commits on Feb 24, 2017
  1. Merge pull request #415 from michaelherold/fix-double-set

    dblock committed Feb 24, 2017
    Prevent warnings and errors when setting Mash keys more than once
  2. Don't log when overwriting Mash keys

    michaelherold committed Feb 24, 2017
    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
Commits on Feb 23, 2017
  1. Add an extension to maintain original Mash keys (#326)

    michaelherold committed Feb 23, 2017
    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.
Commits on Feb 22, 2017