Test equals and hashCode method

[Gueze Thomas]

Hello,

I'm using latest Jmock stable version and I want to use equals and
hashCode methods on mock objects.
But, I notice that theses method are handled in a special way in the
ProxiedObjectIdentity class.

Could you explain the reason of that? Finally, is it possible to use
these methods on mock objects?

Thanks in advance.

--
Thomas Gueze



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[ravisankarvivek]

You mean, you want to know whether these methods can be called with a mock object ?

-Vivek

On Fri, Jul 11, 2008 at 4:56 PM, Gueze Thomas <thomas.gueze@...> wrote:

Hello,

I'm using latest Jmock stable version and I want to use equals and
hashCode methods on mock objects.
But, I notice that theses method are handled in a special way in the
ProxiedObjectIdentity class.

Could you explain the reason of that? Finally, is it possible to use
these methods on mock objects?

Thanks in advance.

--
Thomas Gueze



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[Gueze Thomas]

Exactly.
In fact I have an Set containing a list of object (not mock objects) and
I want to use the contains method on this Set passing a mock object. And
so I have problem with equals and hashCode...

Thanks for the response.

Vivek R a écrit :

> You mean, you want to know whether these methods can be called with a
> mock object ?
>
> -Vivek
>
> On Fri, Jul 11, 2008 at 4:56 PM, Gueze Thomas <thomas.gueze@...
> <mailto:thomas.gueze@...>> wrote:
>
>     Hello,
>
>     I'm using latest Jmock stable version and I want to use equals and
>     hashCode methods on mock objects.
>     But, I notice that theses method are handled in a special way in the
>     ProxiedObjectIdentity class.
>
>     Could you explain the reason of that? Finally, is it possible to use
>     these methods on mock objects?
>
>     Thanks in advance.
>
>     --
>     Thomas Gueze
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

--
Thomas Gueze


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

2008/7/11 Gueze Thomas <thomas.gueze@...>:
> Hello,
>
> I'm using latest Jmock stable version and I want to use equals and
> hashCode methods on mock objects.
> But, I notice that theses method are handled in a special way in the
> ProxiedObjectIdentity class.
>
> Could you explain the reason of that? Finally, is it possible to use
> these methods on mock objects?

Mock objects are used to mock *stateful* objects.  The only reasonable
implementation of equals and hashCode for a stateful object is the
default: object identity.  JMock implements those and deals with the
internal structure of the mock object (proxy and so on) for you.

An object only needs to implement equals and hashCode if it is an
immutable value, in which case it's not worth mocking.  You can just
use the real thing.

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Gueze Thomas]

Alright, I better understand!

Thanks.

Nat Pryce a écrit :

> 2008/7/11 Gueze Thomas <thomas.gueze@...>:
>  
>> Hello,
>>
>> I'm using latest Jmock stable version and I want to use equals and
>> hashCode methods on mock objects.
>> But, I notice that theses method are handled in a special way in the
>> ProxiedObjectIdentity class.
>>
>> Could you explain the reason of that? Finally, is it possible to use
>> these methods on mock objects?
>>    
>
> Mock objects are used to mock *stateful* objects.  The only reasonable
> implementation of equals and hashCode for a stateful object is the
> default: object identity.  JMock implements those and deals with the
> internal structure of the mock object (proxy and so on) for you.
>
> An object only needs to implement equals and hashCode if it is an
> immutable value, in which case it's not worth mocking.  You can just
> use the real thing.
>
> --Nat
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
>  

--
Thomas Gueze


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hilco]

On Fri, Jul 11, 2008 at 5:45 AM, Nat Pryce <nat.pryce@...> wrote:
> Mock objects are used to mock *stateful* objects.  The only reasonable
> implementation of equals and hashCode for a stateful object is the
> default: object identity.  JMock implements those and deals with the
> internal structure of the mock object (proxy and so on) for you.
>
> An object only needs to implement equals and hashCode if it is an
> immutable value, in which case it's not worth mocking.  You can just
> use the real thing.

I don't understand your logic. It is often very useful for a stateful
object to have (an implementation of) equals/hashCode. Moreover, this
is definitely not limited to immutable objects. Just think of
collections: neither stateless nor immutable. Surely, you're not
saying that a decent equals/hashCode would not be useful here?

In fact, I would say the opposite: only a *stateless* object doesn't
need equals/hashCode.

Cheers,
Hilco

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

2008/7/11 Hilco Wijbenga <hilco.wijbenga@...>:
> I don't understand your logic. It is often very useful for a stateful
> object to have (an implementation of) equals/hashCode. Moreover, this
> is definitely not limited to immutable objects. Just think of
> collections: neither stateless nor immutable. Surely, you're not
> saying that a decent equals/hashCode would not be useful here?

Equals is meant to implement the mathematical concept of equals.

If I have two mutable objects that both happen to have the same values
in their instance variables they are not equal.  They behave
independently.  Conceptually, a mutable object represents a
computational process, not a value.  A mutable object cannot be used
as the key in a map, for example.

Collections, unfortunately, have to be treated as a special case
because the Java collections API does not distinguish between mutable
and immutable collections where it should.

> In fact, I would say the opposite: only a *stateless* object doesn't
> need equals/hashCode.

Think of two different instances of String, both containing the
letterrs "bar".  Do you think they should *not* evaluate as equal?

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hilco]

On Fri, Jul 11, 2008 at 12:43 PM, Nat Pryce <nat.pryce@...> wrote:
> 2008/7/11 Hilco Wijbenga <hilco.wijbenga@...>:
>> I don't understand your logic. It is often very useful for a stateful
>> object to have (an implementation of) equals/hashCode. Moreover, this
>> is definitely not limited to immutable objects. Just think of
>> collections: neither stateless nor immutable. Surely, you're not
>> saying that a decent equals/hashCode would not be useful here?
>
> Equals is meant to implement the mathematical concept of equals.

Agreed if by that you mean the contract listed for Object.equals.

> If I have two mutable objects that both happen to have the same values
> in their instance variables they are not equal.

Such a statement is far too broad. It depends on the intent of the
class, on why the class exists. E.g., if I have two Point objects
(each with X and Y coordinates) which happen to have the same values
for X and Y, then I would consider them "equal". Not the *same* but
equal. Wouldn't you?

> They behave independently.

I don't think that's relevant. For objects that are the *same*, yes, I
would not expect them to behave independently. Equality is not an
attribute that can't change. If A and B are equal and then I change A,
then A and B are no longer (necessarily) equal.

> Conceptually, a mutable object represents a
> computational process, not a value.

I've never heard of an object being referred to as a computational
process before. :-) Usually, when talking about a value (in reference
to some object), we mean an immutable object but that's mostly
semantics. An object is simply a combination of state and behaviour
(where the behaviour is dictated by the class). When two objects have
"equal" state (for some definition of "equal") then they are equal.

> A mutable object cannot be used
> as the key in a map, for example.

I agree that it's usually probably not a good idea but it's certainly
possible. If, however, its state changes (to such an extent that its
hash code also changes) while it's in the map then all bets are off.

> Collections, unfortunately, have to be treated as a special case
> because the Java collections API does not distinguish between mutable
> and immutable collections where it should.

I'm not sure what you are referring to here. In general, I don't see
why it's the collection's business which type of objects get stuffed
into it but you may have something more specific in mind.

>> In fact, I would say the opposite: only a *stateless* object doesn't
>> need equals/hashCode.
>
> Think of two different instances of String, both containing the
> letterrs "bar".  Do you think they should *not* evaluate as equal?

:-) Of course, they should evaluate as equal. Are you implying that
String doesn't have state? Obviously it does: the text it represents
(and some housekeeping stuff).

I really feel like you are using definitions of "stateful/stateless"
and "equal" that are different than usual (or at least different than
mine). When do you consider an object to have state? If two objects
are equal, will they be equal as long as they both exist?

To me, the existence of an instance variable implies state (in
general, it's easy to come up with some exceptions) and equality is a
potentially temporary situation, not anything inherent and/or
unchangeable.

Cheers,
Hilco

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email