Re: StringBuffer.equals and StringBuilder.equals gotcha
alexandre_pater...@yahoo.fr wrote:
Trivial or not for old-timers, the more fundamental
problem is the very existence of equals() at the
top of the Object inheritance and the over reliance
on that broken concept.
For a start from a OO point of view this is an heresy.
"Heresy" is an objection to religious dogma on the basis of reason,
and is an accusation leveled by those who have no rationale for their
canon beyond a dictatorial need to control others' thinking.
Properly engaged, an "OO point of view" is not religious dogma, nor is
it supposed to repress rational thinking. Therefore nothing in
programming can be considered "heresy" from that point of view, unless
one is misusing object orientation as a dogma.
Misrepresentation of Josh Bloch's advice does not improve your point.
Not every "modelable" OO entity needs the concept
of equality, far from it actually.
From the context, one must conclude from this that you refer to value
equality. The default behavior of 'equals' is reference identity,
i.e., the same as the '==' operator. All programming, "OO" or not,
"modelable" (quotes in original) entity or not, needs this. Actually.
Then there's the fact that what equals() tries to
grasp simply cannot be made to work in quite some
Huh? What do you mean by "what equals() tries to grasp"? Methods
don't try to "grasp" anything. What are you actually trying to say?
Seriously, I don't know what you mean by this. What is it that you
are saying "equals() tries to grasp"? What 'equals()' actually does
work in all cases.
cases. Actually, in most cases that are about OO
and not about using Java as a procedural language
More religion here.
(granted, equals() works fine when you use Java as a
procedural language and use objects as some kind of
glofiried C structure to put them in Java's generified
Collections classes).
Your language is evocative, but your point is obscure. 'equals()'
works just fine everywhere in Java. Could you be precise about what
you claim does not work, what you mean by "real OO hierarchies" ...
But as soon as you try to model real OO hierarchies,
Not a real Scotsman, eh?
you're stuck if you think for one second that equals()
like most Java programmers use it as any utility at all.
You say "like most Java programmers use it". How is that, and what
objective statistics do you have to show that most Java programmers
use it that way, and what exactly does it lack in utility?
From my own observation and the body of work of thousands or millions
of Java programmers, it seems that 'equals()' has tremendous utility.
Joshua Bloch talks about it in Effective Java and
calls refers to that equals() shortcoming as a a
"fundamental problem".
What "equals() shortcoming"? Is this in /Effective Java/ or some
article somewhere? Are you referring to the difficulty of using
'equals()' in a subclass-to-parent class comparison?
The almighty Tony Morris who used to post here as
'dibblego' many moons ago (ex-IBM JVM engineer and
by far the most knowledgeable person to ever have
posted in this group) and who's now part of the Scala
fame had quite some very interesting things to say
on the subject.
A recent article (2009) on the subject by the author
of Scala:
http://www.artima.com/lejava/articles/equality.html
The only 'workaround' requires to violate the LSP and to
define a "canEqual" method for all your objects.
What that article describes is a problem with any method or process
that is improperly or incompletely applied, or else adapted to
situations for which it is not designed. In summary, the article
states that if you use 'equals()' wrong, e.g., not in conjunction with
a consistently-defined 'hashCode()', that you will get incorrect or
surprising results. Now tell me, in what area of programming will
using a method or technique wrong be a good thing?
Note that the problem with setters in the example in
the article linked to is, like the circle/ellipsis 'problem',
is *not* an OO problem at all but a problem that has to do
with mutability. There are OO languages that do no support
mutability and hence are immune to the circle/ellipsis
problem.
Yet for some reason the languages that do support mutability are far
more widespread and utile.
Your entire diatribe could have been shortened to the link to the
article and conveyed the exact same amount of actual information,
actually. It was a good article; thanks for the link.
--
Lew