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

David Chelimsky dchelimsky at gmail.com
Mon Oct 16 07:14:32 EDT 2006


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