rspec users - Aug 2007 - got/expects causes mental layering violation

I was, for the first time, spec''ing a class that redefined ==.  And my 
spec was incorrect, so == was returning false.

The result was something like:

class C
   def ==(other)
     false
   end
end

.. C.new.should == other...

expected other, got #<C:0x7f03c454> (using ==)

But wait!  Why on earth is == returning the class itself instead of 
true/false?  That shouldn''t be possible.  No, no time for coffee, let
me
go debug this for a few hours... oh.  of course.  == IS returning a 
boolean value, in this case, false; rspec is helpfully showing me 
C.inspect so I can see why they MIGHT differ, assuming I haven''t 
redefined ==.  Which I have.

Would it be good, when == is redefined (or eql? or equals?) for the 
rspec output to indicate somehow what it''s doing and why you might be 
seeing what you''re seeing?  Maybe something like

expected C==other, but C!=other.  You have redefined ==.  C.inspect 
shows: #<C:...>

but much prettier and better worded.

Or do I just call this a learning experience?

Jay

On 8/2/07, Jay Levitt <lists-rspec at shopwatch.org>
wrote:
> I was, for the first time, spec''ing a class that redefined ==. 
And my
> spec was incorrect, so == was returning false.
>
> The result was something like:
>
> class C
>    def ==(other)
>      false
>    end
> end
>
> .. C.new.should == other...
>
> expected other, got #<C:0x7f03c454> (using ==)
What did it really call other? The output should be evaluating a
variable there, not naming it.
> But wait!  Why on earth is == returning the class itself instead of
> true/false?  That shouldn''t be possible.  No, no time for coffee,
let me
> go debug this for a few hours... oh.  of course.  == IS returning a
> boolean value, in this case, false; rspec is helpfully showing me
> C.inspect so I can see why they MIGHT differ, assuming I haven''t
> redefined ==.  Which I have.
>
> Would it be good, when == is redefined (or eql? or equals?) for the
> rspec output to indicate somehow what it''s doing and why you might
be
> seeing what you''re seeing?  Maybe something like
>
> expected C==other, but C!=other.  You have redefined ==.  C.inspect
> shows: #<C:...>
>
> but much prettier and better worded.
>
> Or do I just call this a learning experience?
I must be missing something. I don''t really understand the problem you
are experiencing. Any class can redefine == at any time. Many library
classes do. That''s just part of the language. You defined == to always
return false, so the feedback you got seems to be the feedback you
would expect.

Even if you do explain this differently and I end up seeing it
differently, I don''t think it''s feasible for rspec to be
trying to
discover what methods get defined, overridden, etc, and when.

Cheers,
David
>
> Jay
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

David Chelimsky wrote:
> On 8/2/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>> I was, for the first time, spec''ing a class that redefined ==.
And my
>> spec was incorrect, so == was returning false.
>>
>> The result was something like:
>>
>> class C
>>    def ==(other)
>>      false
>>    end
>> end
>>
>> .. C.new.should == other...
>>
>> expected other, got #<C:0x7f03c454> (using ==)
> 
> What did it really call other? The output should be evaluating a
> variable there, not naming it.
Right.. sorry, I over-simplified the example.  It''s more like:

# class
class C
   def initialize(name, value)
     @name = name
     @value = value
   end

   def ==(other)
     @value == other
   end
end

# spec
..
c = C.new("name", 0)
c.should == 1

# output
expected 1, got #<C:0x7f03c454, @value=0, @name="name"> (using
==)

And that''s confusing at first glance, because it implies that it was 
trying to compare 1 to the whole object, when obviously the redefined == 
function would compare it to C.value (which == 0)!

In an ideal world, rspec would tell me "expected 1, got 0".  But that,
of course, is impossible without reverse-engineering an == function to 
see what it''s really doing.

I''m not sure there is an actual solution, just throwing it out there to
see if my confusion was common...

Jay