From: David Chelimsky <dchelimsky@...>
Date: 2007-01-15T03:06:56+09:00
Subject: Re: possible to un-warn?

On 1/14/07, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> On 1/14/07, David Chelimsky <dchelimsky@gmail.com> wrote:
> > 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.
> >
>
> Unfortunately this happens in parse.y, without any conditional code
> around it. To my knowledge, there is no way to disable the warning
> without recompiling Ruby.

Bummer. Well, you're a rails developer - how much would this syntax
bug you (in this case a new assert_select wrapper)?

response.should have_tag("html:root>head>title", "Login")



>
>