Re: Sort Map on Value
Wojtek wrote:
[...]
This is one of the reasons we do have methods in Interfaces, to ensure
that someone will implement it, and by contract, implement it with the
desired actions.
An interface cannot guarantee that an implementing class provides
a method; it can only guarantee that an implementing class *has* a
method, either implemented directly or inherited from a superclass.
(Or, I guess, "upherited" from concrete subclasses to an abstract
superclass.) The method in question is equals(), which every class can
inherit if it wants, so adding equals() to an interface doesn't "ensure"
anything at all.
If a class/interface needs both compareTo and equals to return
equivalent results for proper operation, then that class/interface
should _require_ it by using both in its defnintion.
Right, but there's no way to express the requirement in Java,
so the Java compiler cannot enforce the requirement or even warn about
possible breaches. You need to rely on programmer-to-programmer
communication channels, Javadoc among them.
And speaking of Javadocs, the compareTo method has the following gem:
"It is strongly recommended, but not strictly required that
(x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that
implements the Comparable interface and violates this condition should
clearly indicate this fact. The recommended language is "Note: this
class has a natural ordering that is inconsistent with equals.""
Not sure why you term this a "gem." It's just a straightforward
statement of purpose, one of those programmer-to-programmer messages
mentioned earlier. If you intend "gem" as sarcasm, I'm unable to see
what you're being sarcastic about.
But in the midst of a coding haze I do not always break off to read
docs. The assumption is that the name of the class/method/parameters
makes sense, and all the requirements are exposed at the code level.
Insofar as feasible, yes. If you can think of a way to write code
that expresses requirements like
- x.equals(y) implies x.hashCode() == y.hashCode()
- x.equals(y) == (x.compareTo(y) == 0)
- Only the EDT can call this method
- This method must return "promptly" less the GUI freeze up
- Classes implementing this interface must provide their very
own versions of equals(), not something inherited
.... then that's great, and an Excellent Good Thing. You'll have enabled
the compiler and tools to ferret out bugs sooner, before they do damage
and run up costs.
But the expressive power of programming languages, including Java,
is rather limited. They're good at expressing some things with great
precision, but completely helpless outside their carefully-circumscribed
scopes. There is no way (as far as I can tell) that Java can express
any of the requirements shown above, so if they're to be expressed at
all they must be expressed in some non-Java medium.
Code is only slightly self-documenting.
--
Eric.Sosman@sun.com