Permalink
Commits on Dec 19, 2017
Commits on Nov 13, 2017
  1. Removed boilerplate text from changelog for 3.5.6 (#426)

    skoolstra committed with michaelherold 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 committed with dblock 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 committed with michaelherold 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
Commits on Feb 20, 2017
  1. Merge pull request #412 from michaelherold/feature/symbolized-keys-fo…

    dblock committed Feb 20, 2017
    …r-mash
    
    Add Hashie::Extensions::Mash::SymbolizeKeys
  2. Add Hashie::Extensions::Mash::SymbolizeKeys

    michaelherold committed Feb 20, 2017
    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).
Commits on Feb 18, 2017
  1. Merge pull request #411 from michaelherold/perf-regression

    dblock committed Feb 18, 2017
    Fix a performance regression due to logging
  2. Fix a performance regression due to logging

    michaelherold committed Feb 18, 2017
    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
Commits on Feb 16, 2017
  1. Merge pull request #409 from CallumD/add_better_rails_detection

    michaelherold committed Feb 16, 2017
    Ensure Railties available when loading Railtie
  2. Ensure Railties available when loading Railtie

    Callum Dryden committed Feb 16, 2017
    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.
Commits on Feb 11, 2017
  1. Merge pull request #406 from michaelherold/fix-propagation-of-disable…

    dblock committed Feb 11, 2017
    …-warnings
    
    Fix propagation of disable warnings
  2. Clean up integration specs to test for STDOUT log

    michaelherold committed Feb 11, 2017
    This standardizes the way we're loading the example applications for the
    integration tests so we're actually testing the behavior of the
    application in each case. They're also structured in such a way to test
    that the Hashie logger doesn't accidentally write to the STDOUT during
    the initialization process of the applications.
Commits on Feb 10, 2017
  1. Merge pull request #402 from dblock/omniauth-oauth2

    michaelherold committed Feb 10, 2017
    Fix #401 w/ integration spec for omniauth-oauth2.