Re: Re: suggestions for newbee

Tom Kaitchuck <[email protected]> Wed, 6 Jul 2005 23:02:46 -0700
Newsgroups gmane.comp.lang.nice.general
Message-ID <[email protected]>
On Wednesday 06 July 2005 9:25 pm, Rohan Hart wrote:
> On Thu, 7 Jul 2005, Tom Kaitchuck said:
>  > Shouldn't ShallowEquals be "==" and DeepEquals be a.equals(b)?
>
> Java coders will expect "==" to be identity.  Not that I wouldn't
> prefer "==" to mean equality (however the object defines it) given the
> number of times I actually want identity.
>
> While we're on the subject... having been tripped up before by the
> default equals method being identity I'd rather it be moved to a new
> Equatable interface without default.  Of course Having an equals
> builder (ShallowEquatable, DeepEquatable) which covered all Equatable
> fields would be nice.  Turning off Object.equals from the Java side of
> the fence might require a new (virtual) root in nice.lang.Object which
> throws OperationNotSupportedException (bet that will be unexpected!).

I'm a little confused here. I understand the need for identity. But my 
understanding is that DeepEquals means that these two objects and their 
constituent objects are DeepEquals all the way down to primitives where they 
have the same content. What then is ShallowEquatable? Is it a object who that 
is ether the same identity or is different but who's sub-elements are the 
same instances? If so is there any reasonable occasion where this would be 
preferred to DeepEquals for reasons other than performance? In such a case it 
would seem preferable to make DeepEquals "equals" and to define 
"shallowEquals" where it is needed.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click