Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > possible to un-warn?

Reply
Thread Tools

possible to un-warn?

 
 
David Chelimsky
Guest
Posts: n/a
 
      01-14-2007
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

 
Reply With Quote
 
 
 
 
Wilson Bilkovich
Guest
Posts: n/a
 
      01-14-2007
On 1/14/07, David Chelimsky <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
 
David Chelimsky
Guest
Posts: n/a
 
      01-14-2007
On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> On 1/14/07, David Chelimsky <(E-Mail Removed)> 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")



>
>


 
Reply With Quote
 
Wilson Bilkovich
Guest
Posts: n/a
 
      01-14-2007
On 1/14/07, David Chelimsky <(E-Mail Removed)> wrote:
> On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> > On 1/14/07, David Chelimsky <(E-Mail Removed)> 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.

 
Reply With Quote
 
David Chelimsky
Guest
Posts: n/a
 
      01-14-2007
On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> On 1/14/07, David Chelimsky <(E-Mail Removed)> wrote:
> > On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> > > On 1/14/07, David Chelimsky <(E-Mail Removed)> 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/artic...tle_less_magic

Cheers,
David


>
>


 
Reply With Quote
 
Wilson Bilkovich
Guest
Posts: n/a
 
      01-14-2007
On 1/14/07, David Chelimsky <(E-Mail Removed)> wrote:
> On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> > On 1/14/07, David Chelimsky <(E-Mail Removed)> wrote:
> > > On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> > > > On 1/14/07, David Chelimsky <(E-Mail Removed)> 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/artic...tle_less_magic
>


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

 
Reply With Quote
 
David Chelimsky
Guest
Posts: n/a
 
      01-15-2007
On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> On 1/14/07, David Chelimsky <(E-Mail Removed)> wrote:
> > On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> > > On 1/14/07, David Chelimsky <(E-Mail Removed)> wrote:
> > > > On 1/14/07, Wilson Bilkovich <(E-Mail Removed)> wrote:
> > > > > On 1/14/07, David Chelimsky <(E-Mail Removed)> 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/artic...tle_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

>
>


 
Reply With Quote
 
David Chelimsky
Guest
Posts: n/a
 
      01-15-2007
On 1/15/07, Gennady Bystritsky <(E-Mail Removed)> 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.
>
>


 
Reply With Quote
 
David Chelimsky
Guest
Posts: n/a
 
      01-16-2007
On 1/15/07, Mark Van Holstyn <(E-Mail Removed)> wrote:
> On 1/14/07, David Chelimsky <(E-Mail Removed)> 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://www.velocityreviews.com/forums/(E-Mail Removed)
> http://lotswholetime.com
>
>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
efficient data loading with Python, is that possible possible? igor.tatarinov@gmail.com Python 10 12-14-2007 04:44 PM
is it possible to possible to create an iterator from a callback interace? aninnymouse@gmail.com C Programming 4 02-21-2006 02:10 PM
XML + XSD: Is it possible to get all possible Values for an Element? Markus Java 1 11-22-2005 02:51 PM
Possible to connect 2 computers via USB? Michael Giroux Wireless Networking 2 09-02-2004 03:27 AM
Possible domain related wireless problem =?Utf-8?B?QWxpIEQ=?= Wireless Networking 0 08-10-2004 01:59 AM



Advertisments