[cal10n-dev] Congratulations on a useful project; here's my suggestion

[Rick Beton]

2009/9/1 Ceki Gulcu <ceki at qos.ch>

>
> No, they do not have different behavior. Both methods act according to
> their respective contracts. Keep in mind that in a typical hashtable the
> actual size of the table is much smaller than the hash space. Thus, it is
> *perfectly* OK for hash values to collide from time to time.


I'm happy with that, but I was thinking about the particular case of several
instances sharing a common enum value but differing in their parameters.
They would all be in the same hashtable bucket so linear searching would be
needed.  If this is sufficiently unlikely, then there is no need to include
the parameters in the hash value.  However, a better hash value is produced
by the more complex code I wrote 3 days ago.



> Not only is the simpler hashCode implementation simpler, it will also be
> faster in computing its result. Since occasional hash collisions are OK, the
> overall results are likely to be better as well. As I said, having args
> contribute to the hashCode is a waste of the code reader/reviewer's time as
> well as CPU cycles. (If unconcinved, write a small test case comparing the
> performance of the two variants.)


The performance is not an issue - in the code I emailed, I had a lazy cache
of the hashcode to avoid the cost of recomputing it (and likewise for
toString()).

As far as complexity is concerned, your simpler approach is much much
better.

I don't really have a strong view on this and I'll leave the choice to you.

Rick :-)
-- 
Big Bee Consultants Limited : Registered in England & Wales No. 6397941
Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/cal10n-dev/attachments/20090901/aaed4bdc/attachment.htm>