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:
> > > 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
>

Is now the appropriate time for me to re-suggest:
@hotel.should.be_booked_solid_on "12/31/2007"