D
David Chelimsky
Hi all,
I'm working on implementing expectation matchers in rspec, so instead of this:
cat.should_eat "tuna"
you would write this:
cat.should eat "tuna"
Now the rub is that this generates "warning: parenthesize argument(s)
for future version". The thing is that, in this case, we know with
some certainty that everything after "eat" is an argument to "eat",
and that the result of "eat" is an argument to "should".
I'd like the ability to be able to tell the interpreter that this is
intentional and to not warn in this case, and I don't want to
accomplish this by turning off all warnings. Is this doable? Does this
strike anybody as nuts? If so, please explain.
The reason I want to do this is that I've run this new syntax by a few
people. Those who write a lot of ruby (not necessarily rails) are
perfectly happy writing it like this:
cat.should eat("tuna") #produces no warning
But, those who write a lot of ruby on rails, not so much. The parens
are not railsy.
In the end, using matchers is a much more flexible and maintainable
approach to expectations, so it's likely that it will become "the
way". The question is whether we can keep all the rails developers who
are already using rspec happy without having to maintain two methods
to achieve the same goal.
Thanks,
David
I'm working on implementing expectation matchers in rspec, so instead of this:
cat.should_eat "tuna"
you would write this:
cat.should eat "tuna"
Now the rub is that this generates "warning: parenthesize argument(s)
for future version". The thing is that, in this case, we know with
some certainty that everything after "eat" is an argument to "eat",
and that the result of "eat" is an argument to "should".
I'd like the ability to be able to tell the interpreter that this is
intentional and to not warn in this case, and I don't want to
accomplish this by turning off all warnings. Is this doable? Does this
strike anybody as nuts? If so, please explain.
The reason I want to do this is that I've run this new syntax by a few
people. Those who write a lot of ruby (not necessarily rails) are
perfectly happy writing it like this:
cat.should eat("tuna") #produces no warning
But, those who write a lot of ruby on rails, not so much. The parens
are not railsy.
In the end, using matchers is a much more flexible and maintainable
approach to expectations, so it's likely that it will become "the
way". The question is whether we can keep all the rails developers who
are already using rspec happy without having to maintain two methods
to achieve the same goal.
Thanks,
David