Re: AspectJ: solution to Java's repetitiveness?
jhc0033@gmail.com wrote:
On Apr 19, 1:31 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
jhc0...@gmail.com wrote:
I'm an experienced and multilingual programmer who, until now, avoided
becoming too familiar with Java.
While I'm very impressed with the Eclipse IDE for Java and the
performance improvements JVM has apparently made, I'm unimpressed by
the amount of error-prone boilerplate code that programming in Java
still requires.
Firstly, there is the pervasive repetitiveness of Java code. For
example, for most classes, it makes sense to define, say, clone(),
equal(), toString(), toXML(), fromString, fromXML() for all of them.
All of these operations follow a very simple pattern that can be
easily formalized. However, Java programmers have to implement each of
these methods by hand for every class. Another common example is the
trivial getters and setters.
I'd agree on toString() but on none of the others.
Why?!
If you agree on toString(), why not fromString() and toXML(),
fromXML(), etc?
Personal experience (which may, of course, differ from
your personal experience). I have often implemented toString(),
I have often implemented equals() and hashCode(), but I have
never implemented clone() nor any of the others you mention.
What, never? No, never! What, ne-verrrrr? No, NEVER! Which
makes me disagree with your assertion that "most" classes need
these things.
I've looked at a 10kLOC Java project (written by an extraordinarily
smart fellow, incidentally) that implements cloning/copy-construction
for almost every class, following this simple rule, essentially: to
clone this object, clone its every field. Why doesn't Java automate
this? Even C++ creates copy constructors with this semantics for you.
As I said, I've never, not even once, implemented clone().
It's always seemed to me to be a method that walks on the wild
side. IIRC Bloch uses the term "extra-linquistic" to describe
it, pointing out that its ability to create objects without
running a constructor amounts to an end-run around many of the
expectations of object creation.
The only times I've ever found a use for clone() have been
to make defensive copies of private arrays.
Why not
b = new Bar(x, y);
Calendar cal = new GregorianCalendar();
Number num = new Double(42.0);
I can only imagine this being useful if you rebind the variable,
assigning it a value of a different subtype:
There's a maxim favored by O-O purists: "Code to the
interface, not to the implementation." So in the above, one
would like to proclaim to the world "I have in my hand a
Number" while keeping private the fact that in this case it
just happens to be a Double. I see this even more frequently
with collections:
List<? extends Number> list = new LinkedList<Double>();
You happen to know that `list' is a LinkedList and that the
elements it contains are Doubles, but you'd prefer to keep the
details to yourself: As far as the rest of the code is concerned,
`list' is just some unspecified kind of List, and its elements
are (one) unspecified flavor of Number. Why be more specific
when you don't need to be?
... and unless you want to reveal the innards, you need a
way to express both the "external type" and the "internal type"
and to allow them to be different.
--
Eric Sosman
esosman@ieee-dot-org.invalid