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