Re: Confused about StringBuilder equals
Thomas Kellerer wrote:
Patricia Shanahan wrote on 23.10.2007 20:23:
A StringBuilder is equal to itself, and nothing else. Anything else
would be a bad idea, given the fact that StringBuilder is not only
mutable, it is positively designed for change.
There are classes in the JDK that are mutable and still implement a
decent equals() method (e.g.: Point, AbstractList, Date).
AFAIK, the classes that are mutable and have an actual comparative
equals() method fall into two categories:
1. Collections and related components.
2. Classes that are mutable by design mistake (e.g., Point, Date).
The second category should generally be assumed (except for defensive
purposes) to be used immutably, so the verity of equals /should/ remain
constant throughout all points of time, so they are an exception to the
rule that `mutability should generally not use equals.'
The first category has two use cases: highly ephemeral instances with
high mutability, and long-term backings for which changes are made only
sporadically. It is for the latter purpose where equals() comes in.
So why shouldn't it be possible for StringBuilder to implement equals()
based on comparing all characters and thus avoiding the overhead of
copying the char array around just for comparing.
I would very much appreciate that and I don't see a problem with the
fact that it's mutable.
The problem with StringBuilder -- and any other class with similar usage
patterns -- is that it only exists for the small amount of time in which
it is constructing the final object. It is not only mutable, but it does
not really have a sense of an immutable state or use case. The equals()
method implies some sort of immutability which can generally be
supplied, but which is generally idiotic in the use case of
StringBuilder, since it shouldn't exist for long as a StringBuilder.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth