[rspec-devel] [Rspec-users] subject.should_be true

David Chelimsky dchelimsky at gmail.com
Mon Oct 16 07:30:10 EDT 2006


On 10/16/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 10/16/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 10/16/06, David Lee <david at davelee.com.au> wrote:
> > > thanks, Aslak. I read it.
> > >
> > > I still think what i first did, which is that .should_be true should
> > > be more lax than should_equal true.
> > >
> >
> > ri Object.==
> >
> > -------------------------------------------------------------- Object#==
> >      obj == other        => true or false
> >      obj.equal?(other)   => true or false
> >      obj.eql?(other)     => true or false
> > ------------------------------------------------------------------------
> >      Equality---At the +Object+ level, +==+ returns +true+ only if _obj_
> >      and _other_ are the same object. Typically, this method is
> >      overridden in descendent classes to provide class-specific meaning.
> >
> >      Unlike +==+, the +equal?+ method should never be overridden by
> >      subclasses: it is used to determine object identity (that is,
> >      +a.equal?(b)+ iff +a+ is the same object as +b+).
> >
> >      The +eql?+ method returns +true+ if _obj_ and _anObject_ have the
> >      same value. Used by +Hash+ to test members for equality. For
> >      objects of class +Object+, +eql?+ is synonymous with +==+.
> >      Subclasses normally continue this tradition, but there are
> >      exceptions. +Numeric+ types, for example, perform type conversion
> >      across +==+, but not across +eql?+, so:
> >
> >         1 == 1.0     #=> true
> >         1.eql? 1.0   #=> false

Actually, now that I think about it, if we're really aligning w/ ruby
syntax and intent, we should just use the language:

subject.should_equal value passes only if subject.equal? value passes
subject.should_eql value passes only if subject.eql? value passes
subect.should == value passes only if subject == value passes

Because RSpec supports arbitrary predicates and operators, we just
need to remove the special handling of these cases and it will work
correctly.

Then we have to have the (what I expect to be) unpleasant debate about
whether to deprecate should_be (which is what I think we should do).

Cheers,
David


> >
> > So in Ruby, == is more lax than equal?
> > "2" == "2" #=> true - it's "lax"
> > "2".equal? "2" #=> false - it's "strict"
> >
> > Currently in RSpec:
> > should_be uses Object.equal? - object identity.
> > should_equal uses Object.== - object "similarity"
>
> This is not accurate. Currently in RSpec:
> should_be uses Object.equal? UNLESS we're dealing w/ booleans
> should_equal uses ==
>
> per other email in this thread, I don't think we should make these exceptions.
>
> >
> > In other words - currently in RSpec should_equal is more "lax" than should_be.
> >
> > This is contrary to your recommendation.
> >
> > What we *could* do is to change RSpec's implementation of should_be
> > and should_equal to:
> >
> > should_equal uses Object.equal?
> > should_be uses Object.==
> >
> > This would be more consistent from a Ruby pespective, but perhaps not
> > from an English perspective. Example: I'm more willing to say that two
> > dollar bills A and B are equal, but I wouldn't say that dolar bill A
> > *is* dollar bill B (A.should_be B). So in English things are a bit
> > different than in Ruby.
> >
> > I think it boils down to: Do we want to be faithful to English or to
> > Ruby's definition of "equal" and the similar but very different
> > "is/be/==".
> >
> > Aslak
> >
> > > I'd expect
> > >
> > > 1.should_be true    # pass
> > > 1.should_equal true # fail
> > >
> > > the former being equivalent to assert; the latter to assert_equal
> > >
> > > cheers,
> > > David Lee
> > >
> > >
> > > On 16/10/2006, at 7:39 PM, aslak hellesoy wrote:
> > >
> > > > On 10/16/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > >> As things stand now, the following will all pass:
> > > >>
> > > >> true.should_be true
> > > >> "true".should_be true
> > > >> "false".should_be true
> > > >> 3.should_be true
> > > >> etc
> > > >>
> > > >> My feeling is that "should_be true" should only pass if it returns
> > > >> boolean true even though ruby says that non-nil/non-false is true.
> > > >>
> > > >
> > > > The old discussion about this topic is here:
> > > > http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228
> > > > (The "5.should.be true" thread)
> > > >
> > > > I recommend reading it.
> > > >
> > > >> Anybody else?
> > > >>
> > > >> David
> > > >> _______________________________________________
> > > >> Rspec-users mailing list
> > > >> Rspec-users at rubyforge.org
> > > >> http://rubyforge.org/mailman/listinfo/rspec-users
> > > >>
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>


More information about the rspec-devel mailing list