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

David Lee david at davelee.com.au
Mon Oct 16 07:46:14 EDT 2006


Thesis:  should_be is inherently too ambiguous for its intended use,  
as its assumed meaning depends entirely on the nature of the thing  
being compared.

eg, 3 + 2 should be 5 (an abstract article; == is appropriate)
this rug should be my old favourite rug (equal? )
this rug should be a red square rug from Ikea ( eql? )

it says nothing about what it means to ' be'.

It's too .. agnostic.

cheers,
David Lee


On 16/10/2006, at 9:30 PM, David Chelimsky 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).
>
> 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