en passant: is IndexingObjectStore safe?

[Ian Young]

On 15 Jan 2014, at 16:44, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 1/15/14, 11:41 AM, "Ian Young" <ian at iay.org.uk> wrote:
>> 
>> I should have said hashCode() explicitly, as that's what the class is
>> using to detect "different" objects. My point is that this isn't
>> sufficient to tell objects apart, unless you only define the class to be
>> valid across objects where hashCode() comparison is the same as content
>> equality, which is not in general the case.
> 
> It seems like actual equality here is the only foolproof test criteria for
> reusing an object,

I think that's right. The premise of the class at present, though, is that you get back an index equal to the hashCode() that you can use to retrieve the object... and you can't have both of those things unless you never put in two objects which are not equal() but have the same hashCode(). That's *usually* going to be true, but is definitely not guaranteed.

My proposal was to manufacture a sequence number to use as an index instead of relying on the hashCode(), and relying on something like HashMap's internals to efficiently deal with chains of things with the same hashCode().

> though of course one would have to be certain the
> objects stored implemented equals() correctly.

Right, my original mail mentioned as an alternative that 

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20140115/abef47a9/attachment.bin