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

[Ceki Gulcu]

Rick Beton wrote:
>     Moreover, you could implement hashCode as follows, which correct and
>     efficient at the same time. Having args contribute to the hashCode
>     is a waste of time.
> 
>      @Override
>      public int hashCode() {
>        return e.hashCode();
>      }
> 
> 
> That's probably better (simpler often means better), but now hashCode() 
> and equals() have different behaviour so there ought to be a remark in 
> the JavaDoc to say so.  It could, for example, mean that a hashtable of 
> instances may be less efficient because more linear searching might happen.

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.  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.)

>     How about renaming ResourceMessage as MessageParameterObj. See also
> 
>      http://www.refactoring.com/catalog/introduceParameterObject.html
> 
> 
> I see from the Git patch email you've already done this.  :-D

Indeed, but I am open to suggestions.

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