possible to un-warn?

Discussion in 'Ruby' started by David Chelimsky, Jan 14, 2007.

  1. 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
     
    David Chelimsky, Jan 14, 2007
    #1
    1. Advertising

  2. On 1/14/07, David Chelimsky <> 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.
     
    Wilson Bilkovich, Jan 14, 2007
    #2
    1. Advertising

  3. On 1/14/07, Wilson Bilkovich <> wrote:
    > On 1/14/07, David Chelimsky <> 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")



    >
    >
     
    David Chelimsky, Jan 14, 2007
    #3
  4. On 1/14/07, David Chelimsky <> wrote:
    > On 1/14/07, Wilson Bilkovich <> wrote:
    > > On 1/14/07, David Chelimsky <> 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.
     
    Wilson Bilkovich, Jan 14, 2007
    #4
  5. On 1/14/07, Wilson Bilkovich <> wrote:
    > On 1/14/07, David Chelimsky <> wrote:
    > > On 1/14/07, Wilson Bilkovich <> wrote:
    > > > On 1/14/07, David Chelimsky <> 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


    >
    >
     
    David Chelimsky, Jan 14, 2007
    #5
  6. On 1/14/07, David Chelimsky <> wrote:
    > On 1/14/07, Wilson Bilkovich <> wrote:
    > > On 1/14/07, David Chelimsky <> wrote:
    > > > On 1/14/07, Wilson Bilkovich <> wrote:
    > > > > On 1/14/07, David Chelimsky <> 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"
     
    Wilson Bilkovich, Jan 14, 2007
    #6
  7. On 1/14/07, Wilson Bilkovich <> wrote:
    > On 1/14/07, David Chelimsky <> wrote:
    > > On 1/14/07, Wilson Bilkovich <> wrote:
    > > > On 1/14/07, David Chelimsky <> wrote:
    > > > > On 1/14/07, Wilson Bilkovich <> wrote:
    > > > > > On 1/14/07, David Chelimsky <> 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"


    YES!!!!!!!!!!!

    Inspired by your question, I played around for a minute w/ a means of
    supporting all three sets of syntax w/ one set of matchers. The result
    is not complete yet, but right now the trunk supports all of these
    forms for some of the expections:

    result.should_equal 5
    result.should.equal 5
    result.should equal(5)

    When I'm done, you'll be able to use most of the expectations with any
    of the three forms, though using the "_" or "." forms for custom
    expectations will require monkey patching an RSpec class, so it will
    be an "at your own risk" sort of scenario.

    Thanks for bringing this up Wilson!

    Cheers,
    David

    >
    >
     
    David Chelimsky, Jan 15, 2007
    #7
  8. On 1/15/07, Gennady Bystritsky <> wrote:
    > David Chelimsky wrote:
    > >>
    > >> Is now the appropriate time for me to re-suggest:
    > >> @hotel.should.be_booked_solid_on "12/31/2007"

    > >
    > > YES!!!!!!!!!!!
    > >
    > > Inspired by your question, I played around for a minute w/ a means of
    > > supporting all three sets of syntax w/ one set of matchers. The result
    > > is not complete yet, but right now the trunk supports all of these
    > > forms for some of the expections:
    > >
    > > result.should_equal 5
    > > result.should.equal 5
    > > result.should equal(5)
    > >
    > > When I'm done, you'll be able to use most of the expectations with any
    > > of the three forms, though using the "_" or "." forms for custom
    > > expectations will require monkey patching an RSpec class, so it will
    > > be an "at your own risk" sort of scenario.
    > >
    > > Thanks for bringing this up Wilson!
    > >
    > > Cheers,
    > > David

    >
    > You may have missed it, but it was exactly what I have suggested (or
    > imlied to suggest) in my first reply to you ;-)


    Ah - I did miss it.

    What Wilson is talking about has a bit more context. We've been
    through a number of variations of rspec syntax. everything.with.dots
    was one, everything_with_underscores was another, and we've even had
    some.dots.and.some_underscores.

    Wilson was suggesting that we return to a previous version of the
    syntax where the receive.and.should get dots but
    everything_after_should gets underscores.

    Regardless, thanks for the suggestion (or implication thereof).

    Cheers,
    David

    >
    > Anyways, glad the idea got through other channels :)
    >
    > Gennady.
    >
    >
     
    David Chelimsky, Jan 15, 2007
    #8
  9. On 1/15/07, Mark Van Holstyn <> wrote:
    > On 1/14/07, David Chelimsky <> wrote:
    > >
    > > response.should have_tag("html:root>head>title", "Login")

    >
    >
    > What about doing something like:
    >
    > respoonse.should :have_tag, "html:root>head>title", "Login"
    >
    > Then should can just call have_tag with all the given arguments?


    That idea came up a long time ago on the rspec list and got a pretty
    quick thumbs down. It does seem to simplify things from a maintenance
    perspective, but no more so than this:

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

    Anyhow - I think that we should probably move this discussion over the
    rspec-users list:

    http://rubyforge.org/mailman/listinfo/rspec-users

    Cheers,
    David


    >
    >
    >
    >
    > --
    > Mark Van Holstyn
    >
    > http://lotswholetime.com
    >
    >
     
    David Chelimsky, Jan 16, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jason L. Woodruff

    how to warn?

    Jason L. Woodruff, Sep 9, 2004, in forum: Perl
    Replies:
    1
    Views:
    676
    Andres Monroy-Hernandez
    Sep 10, 2004
  2. Elmo Watson

    Trace.Warn

    Elmo Watson, Oct 29, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    579
    Elmo Watson
    Oct 29, 2003
  3. Tone Curtis
    Replies:
    3
    Views:
    4,536
    Tone Curtis
    Jun 10, 2004
  4. Replies:
    7
    Views:
    25,955
    rohit.net100
    Feb 28, 2011
  5. =?Utf-8?B?Tkg=?=

    Warn user that session expired?

    =?Utf-8?B?Tkg=?=, Jan 6, 2006, in forum: ASP .Net
    Replies:
    6
    Views:
    4,196
    Peter Rilling
    Jan 6, 2006
Loading...

Share This Page