Re: 1GB Tables as Classes, or Tables as Types, and all that refuted

I've reread Mr Gittens, and I'm still not convinced.

The probelm is that the Object Identity is dependant upon runtime details. In memory with Java it is a reference to the memory that was allocated to contain the object.

As I say above, this works, it has performance advantages, but it over complicates things.

For a start need to have two different operators for equality. Three if you include instanceof.

In addition to multiple operators there are different means for identifying an object. First there is the reference. This is extremely error prone.

Then there is the hashcode. This can only be used to disprove equality, since different hash codes can share the same hash.

Then there is the long hand comparison of the state, where each of the members is compared. This is the only accurate test for equality.

It introduces the opportunity for bugs. If either the hash or equals methods contain a bug then strange things can happen. Strange things that are very difficult to fix.

Since the comparison is recursive, this bug will also affect every other dependant object.

Then things are complicated further when persisting objects. The objects have to be provided with a persistant reference id, with all relationships between objects being preserved.

With hard work and dilligence it can all be made to work, but just look how difficult it is to create a persistant singleton:

http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton.html There has to be an easier way. Received on Mon Dec 13 2004 - 15:20:41 CET