[Rspec-devel] support for arbitrary comparisons

David Chelimsky dchelimsky at gmail.com
Wed Sep 6 12:28:04 EDT 2006


On 9/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 9/6/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 9/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 9/6/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > Mike Williams contributed a patch to support arbitrary comparisons.
> > > > This is now in the trunk and will be part of the next release. So you
> > > > will now be able to do this:
> > > >
> > > > result.should_be < 5
> > > > result.should_be >= 7
> > > >
> > > > It also supports alternate syntax for should_be, should_match
> > > >
> > > > result.should == 3
> > > > result.should =~ /regex/
> > > >
> > > > Personally, I prefer should_be and should_match in these cases, as I
> > > > think they read better. Anyone else have opinions about that?
> > > >
> > >
> > > I prefer should_match and should_equal too, but I don't expect
> > > everyone to feel the same. I think it's great to support both.
> >
> > Fair enough.
> >
> > > I don't see a problem with making this official now and add it to the
> > > website documentation. Dave's cheatsheet (which is not in svn - grr)
> > > should be updated too.
> >
> > In the process of doing so (not on the cheatsheet).
> >
> > > > This patch also supports using methods that are not formatted like
> > > > predicates but act like them:
> > > >
> > > > def whatever
> > > >   true
> > > > end
> > > >
> > > > subject.should_be_whatever
> > > >
> > > > I really object to this on philosophical grounds. Ruby predicates are
> > > > a beautiful construct, and I personally feel that if you're writing
> > > > methods like that you are violating a ruby aesthetic. If you agree
> > > > with that, then you have to agree that supporting them in rspec also
> > > > violates the same aesthetic. To that end, even though they work, they
> > > > will not be offically supported at this point (i.e. you can use them,
> > > > but they may go away some day).
> > > >
> > >
> > > I agree we shouldn't support non-questionmark "predicates". Let's make
> > > the day support for it goes away be today ;-)
> >
> > The only problem with explicitly not supporting them (i.e. not letting
> > them work at all) is that it gums up the rspec code which is currently
> > quite general. My thinking is that if it is in the docs, it is
> > supported. Otherwise you're on your own.
> >
> > What do you think?
>
> Fair enough. A non-documented feature is a non-feature.

Changed my mind. It was way too simple to add the non-support and
clarify what is supported directly in the code. So I've checked in the
non-support for non-predicates.

You can still do this:

target.non_predicate.should_be true (or false)

Cheers,
David


More information about the Rspec-devel mailing list