[rspec-devel] [Rspec-users] subject.should_be true
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
> > 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
More information about the rspec-devel