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

[Ceki Gulcu]

Rick Beton wrote:
> 2009/9/1 Ceki Gulcu <ceki at qos.ch <mailto: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.

Indeed, it would be possible to come up with MessageParamObj instances with 
common keys but differing in their args. In that case, your impl would be 
perform better. However, I don't think such cases are likely to occur and can be 
safely ignored.
> 
>     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()).

You still have to compute the hash code the first time. It is often the case 
that the hash code for an object is computed only once and repeatedly on 
different object instances having the same or different contents.  In such a 
scenario, there would be many cache misses...

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

Well, it's simpler. :-)

I still don't see an obvious use-case where MessageParamObj instances would be 
inserted into a map, not to say that it could not happen.

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

OK. Thank you for being cool headed about this. I appreciate that.


> Rick :-)
-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch