[erlang-patches] [jinterface] added OtpMbox.hash()

[Vlad Dumitrescu]

Hi,

On Wed, Sep 22, 2010 at 23:19, Gábor Lipták <gliptak@REDACTED> wrote:
> OtpErlangPid currently does not implement hashCode() , so forwarding
> from OtpMbox to OtpErlangPid still might not define identity
> correctly. As OtpErlangPid overrides equals(), it should also have
> hashCode() implemented.

That's correct, I don't understand why some runs of the static
analysis didn't return all the cases. All classes based on
OtpErlangObject are affected, because OtpErlangObject.hashCode caches
and does lazy initialization on the value which is really computed by
doHashCode() which in its turn is overriden in the subclasses.

This works, but I'd like to argue that it's not optimal because the
static analysis can't give any warning when one really forgets to
write hashCode(). My suggestion is that each hashCode() do their own
caching and use a helper class or method to combine the required
fields. I can provide an implementation of that, if needed. This way
we can rely on the static analysis to point out if we do something
wrong.

The obvious argument to keeping the status quo is that it works now
and there's not going to be any changes to the jinterface classes. For
what it's worth, I do have in erlide a couple of classes extending the
jinterface ones (for example, for representing patterns we need
variables and cons cells).

Also, we have to remember that having a hashCode() implementation
doesn't guarantee that it's doing the right thing. Getting equals()
and hashCode() and compareTo()  (if implementing Complarable)
consistent can be difficult.

best regards,
Vlad