On 1/14/07, Wilson Bilkovich <wilsonb / gmail.com> wrote:
> 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.

Remember the whole sugar causes cancer thing? I've added suppport for
expectation matchers in part to solve that problem. You can read about
it here:

http://blog.davidchelimsky.net/articles/2007/01/10/rspec-should-use_a_little_less_magic

Cheers,
David


>
>