Fix rspec 3 deprecation warning

[schneiderderek]

Issue: https://github.com/chancancode/json_expressions/issues/27

[chancancode]

Sorry, but I'm a bit confused. Doesn't this simply flip the name of the methods in the definition? At the end of the day, we still have the same two methods defined, is that correct? Does that make a difference for rspec somehow?

[schneiderderek]

@chancancode In short, yes it does make a difference for rspec and it does pretty much flip the method definitions. The methods still have the same functionality, but are named differently and the aliases changed to be in complience with Rspec 3. See: https://www.relishapp.com/rspec/rspec-expectations/docs/changelog under section: 3.0.0.beta2 / 2014-02-17 in the 'Enhancements' list.

From what I understand because of the new expect syntax that rspec is using, rspec expects the two methods failure_message and failure_message_when_negated to be overridden for your custom error messages. Reference: https://www.relishapp.com/rspec/rspec-expectations/v/3-0/docs/custom-matchers/define-matcher#overriding-the-failure-message

Before the change, the methods failure_message_for_should_not and failure_message_for_should were being overridden. To support overriding the methods failure_message and failure_message_when_negated they were being aliased to failure_message_for_should_not and failure_message_for_should, respectively. Rspec does not seem to like this, which is were the deprecation warning comes from.

[chancancode]

I'm still not sure why flipping this would solve the problem. The end result here should be exactly the same – we have the same 4 methods defined on our class – and they are all equally "real" methods.

It seems the problem lies within whoever is calling these methods. Do you have a stack trace from the deprecation warning by any chance?

To be clear, merging this is not an issue, I just want to understand the real problem and address the root cause directly.

[schneiderderek]

@chancancode I am not entirely sure what the 'exact' issue is. My current assumption is that it has something to do with how aliased methods work with methods that are being overridden by a subclass. But, I am still trying to prove/disprove that.

I do not have a stack trace, I did throw in the option for rspec to throw an error if a deprecation warning comes up, but that did not produce a stack trace.

I definitely understand. Like I said I am not 100% certain of the issue either, but I am working on trying to figure it out.

[chancancode]

Thanks for sitting through this with me :blue_heart:

One idea to debug this would be to actually define all four of the methods without using alias_method and see what happens. You can also change the implementation of the old methods to raise "omg", perhaps that would help us get a stacktrace ;)

Otherwise there's always the option to bundle open rspec-expectations and change the code there locally :P

[schneiderderek]

@chancancode No problem, I am happy to help. :smile:

As soon as I get a chance, I will try what you have suggested and get back to you on what I find.

[workingtechnology]

@schneiderderek I was having the same issue, however on closer inspection I noticed the latest gem published to rubygems.org was older than the previous commit to address this.

In the meantime I have installed directly from the GitHub repo and all is well.

I'm not sure if this is related to your issue?

[schneiderderek]

@workingtechnology Good call. I didn't even think to look at that. This does resolve my issue. Thanks!

[schneiderderek]

@chancancode This PR is no longer needed, so i'm going to close it.

[chancancode]

Oops, my bad! I'll do a release today

[CoffeeAndCode]

Hi @chancancode, any word on the new release?

[chancancode]

Sorry about this :cry: it's up now! http://rubygems.org/gems/json_expressions/versions/0.8.3

[CoffeeAndCode]

You rock! Thanks!