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

aslak hellesoy aslak.hellesoy at gmail.com
Mon Oct 16 07:37:21 EDT 2006


On 10/16/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> 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).
>

That sounds like the right thing to do. Should we deprecate
should_equal in the same swoop? (or at least remove it and let it be
handled magically like any other predicate)?

Aslak

> 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
> > >
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the rspec-devel mailing list