Add #except under Ruby 3

[jackjennings]

Ruby 3 adds the Hash#except method, which should return the correct Hashie object instance when called on a Mash or object using the Hashie::Extensions::IndifferentAccess mixin.

This change implements #except in both of those locations and adds the corresponding specs.

[michaelherold]

Hi @jackjennings, thanks for the submission! We're in a bit of a pickle right now because we haven't merged #543 yet to move over to Actions from Travis. When one of us has the chance we'll get that merged so we can rebase this and double-check that everything is green.

I don't see anything concerning and agree this should be in the gem. There's a little bit of ambiguity in the way you're calling #slice that I just want to make sure about.

Also, we haven't been testing against 3.0 so I don't know if there anything that we need to clear up for the keyword argument changes.

Anyway, I wanted to get you a response since I was looking at my email when you submitted the PR. Please bear with us!

[jackjennings]

@michaelherold no rush on my end. This was an issue that arose in an app I'm working on that uses Searchkick, which extends hashie's mash, and calling except starts returning a hash in Rails 6.1 under Ruby 3. I've worked around it (for anyone that lands here before merging) by just wrapping the return value in a new Mash.

The except method definition is actually lifted from Rails' core_ext, but I agree with you that this isn't super clear. A potential alternative would be to not use the slice implementation, but drop down to the native implementation and then re-wrap in a new instance (the same implementation as slice, actually):

def except(*keys)
  string_keys = keys.map { |key| convert_key(key) }
  self.class.new(super(*string_keys))
end

There is some elegance in defining except as a kind of inverse of slice, but let me know what your preference is and I'm happy to update this PR.

[jackjennings]

@michaelherold which implementation do you prefer? I’ll update this PR to be ready to merge now that the CI work is done

[michaelherold]

I'm good with the current implementation that you have. I'm not sure what I was thinking back then but I don't see anything ambiguous now. 😅

I think we just need a rebase!

[jackjennings]

I ended up swapping it out with the super-based implementation to avoid some additional method calls with re-converting keys into strings. Rebased with latest changes, but looks like a maintainer needs to approve running workflows.

[jackjennings]

@michaelherold looks like danger failed on my force-pushed change — not really sure what to do…?

[dblock]

Noticed some extra quote in https://github.com/hashie/hashie/pull/545/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edL43, maybe you can fix that one too? :) Obviously won't hold this PR for that. I kicked off CI.

[jackjennings]

@dblock — not sure what you mean by an extra quote; the link that you posted doesn't point to a specific line.

[dblock]

@dblock — not sure what you mean by an extra quote; the link that you posted doesn't point to a specific line.

Yeah sorry not sure what happened here, search for [#533](https://github.com/hashie/hashie/pull/533) in CHANGELOG, it's got a quote in to_json that messes up formatting.

[jackjennings]

@dblock fixed it.

[dblock]

Dunno what's up with Danger. @michaelherold cool to merge with me.

[jackjennings]

@michaelherold good to get this in?

[jackjennings]

@michaelherold Can this be merged in, or should I close it? I know this is probably not particularly pressing.

[dblock]

@jackjennings I am a little worried about the failing integration test, can you please take a look? Force push let's get CI passing?

[dblock]

Verified that this will be 🍏 in #552.