[
https://issues.apache.org/jira/browse/MATH-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269529#comment-13269529
]
Gilles commented on MATH-786:
-----------------------------
bq. Do you have a use case at hand that requires this change?
It's an optimization suggested by a developer who works with maps.
I have no idea how much gain it provides; but it seems that for an application
that calls "hashCode" a lot, that might be useful...
I don't understand why you call it "premature" optimization.
If the Javadoc states that the correct behaviour is up to the user, I don't see
any real problem; we have other cases where a flag indicates that a reference
is stored, and if the user does something he shouldn't, the same "problems"
will be created.
What I propose seems the perfect compromise between always assuming immutable
(the two Seb's opinion) and never optimize "hashCode" (your opinion). The
default being no optimization so that users are not bitten by surprise.
Shall I apply the change?
> "hashCode" in "Pair" class
> --------------------------
>
> Key: MATH-786
> URL: https://issues.apache.org/jira/browse/MATH-786
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Gilles
> Assignee: Gilles
> Priority: Trivial
> Fix For: 3.1
>
>
> Since "Pair" is supposed to be an immutable class, couldn't we cache the
> "hashCode" value at construction? That would supposedly make it more
> efficient when used in maps.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
