On 1/14/07, David Chelimsky <dchelimsky / gmail.com> wrote:
> 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")
>

That looks totally fine. "Even" as a Rails developer, I use parens
like that to disambiguate things, visually.

Anyone who can't handle some parentheses occasionally shouldn't be a
developer. Heh.

That being said.. why wouldn't that just be: should_have_tag ?
I haven't seen anything about this change on the mailing list.

--Wilson.