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?
Because you don't need them.
toString is used for writing debug output out. No similar requirements
exist for input.
toXML and fromXML are covered by several XML API's XML bean
serialization, JAXB, StAX etc..
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?
If you checked some more Java source, then you would see that this
is not the standard.
Even C++ creates copy constructors with this semantics for you.
C++ default copy constructor has caused problems for many beginner
C++ programmers as well.
If you'd prefer a more "declarative" style for your coding,
you might want to look into using annotations. I haven't used
them extensively myself, but the framework looks rich enough to
support "This instance variable does/doesn't influence the
toString()/equals()/hashCode()/compareTo()/... methods."
I'll look into these, but Wikipedia says annotation processors can not
modify the annotated code itself. I'm guessing they mean that if a
class doesn't have a method written, annotation processors can not add
one?
It can create new methods in a new class that extend and/or delegate to
the original class.
Arne