AspectJ: solution to Java's repetitiveness?

[Ramon F Herrera]

Bar b = new Bar(x, y);
Why not
b = new Bar(x, y);
or
b = Bar(x, y);

Due respect but...

That has to be one of the worst features I have ever seen in a
programming language.

If you want conciseness, how about shortening the above to 'b-x-y'?

I bey you are programming from a cell phone (r u?). People with
regular 103-key keyboards don't mind typing the few extra characters.

-Ramon

 

[EricF]

Yup, here we go:

package testaj;

import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class Test {

@After("execution (* sayHello())")
public void sayAgain(){
System.out.println("again\n");
}

}

I do find the annotations to be a bit easier to read.

<http://www.jroller.com/ramlog/entry/using_the_aspectj_plug_in1>

For NetBeans 6.0, no less!

The annotations are relatively new. They are certainly easier to read.

My use of regular expressions wasn't literal, but here's an example from the
Wikipedia:

pointcut set() : execution(* set*(*) ) && this(Point) &&
wiithin(com.company.*);

Looks like 1 to me.

Eric

 

[Arved Sandstrom]

I disagree. Well, partly - Javadocs are there to tell what the code does.
Comments are there to tell why it does it. The code itself should tell
you what it does, and that's why Java's alleged "verbosity" is valuable.

Our use of English here may be causing some confusion. Eric also used "why"
to describe comments that are useful (see his response to my above). I would
have used the word "what". Maybe it's a regional thing.

I'd tend to use "what" to characterize a comment that is actually describing
what a chunk of code is doing, just not at a very low-level. Not even in
Java is code always that self-descriptive. I'd reserve a "why" comment for
explaining a particular implementation decision, especially if it's not the
first thing that springs to mind.
[ SNIP ]

AHS

 

[Arved Sandstrom]

I bey you are programming from a cell phone (r u?). People with
regular 103-key keyboards don't mind typing the few extra characters.

And if they do mind, then they shouldn't have picked a profession in which
the single most important physical skill is typing. [SNIP ]

I resemble that remark.

Seriously, I have only ever typed with two fingers. I may be one of the
world's fastest two-fingered typists, though.

Not in three decades of being behind keyboards have I ever felt the need to
be a full-fledged touch typist. Nobody writes code or documentation so fast
that their typing prowess (or lack of it) should be a drawback. Well, OK,
hunt and peck would be a problem.

AHS

 

[jhc0033]

Nobody writes code or documentation so fast
that their typing prowess (or lack of it) should be a drawback.

Some people do. Read the first comment there:

http://hathawaymix.org/Weblog/2004-06-16

"I recall how one day I walked out of work and my hands hurt so much
from typing Java code, because Java is so needlessly verbose."

 

[RedGrittyBrick]

The important thing is that no programmer should ever use "too much
typing" as an excuse for anything. The important thing isn't the effort
of the original programmer's typing, but later maintainers' and ops
personnel's effort to read and maintain that code. Insistence on
shaving off a few dozen keystrokes at the expense of operations is a
false economy and actionable laziness.

Sometimes I tire of typing code like

CleverGreenThing<WingNut, CorkScrew, BathTub> foo
= new CleverGreenThing<WingNut, CorkScrew, BathTub>();

I wonder if my IDE can (be trained to) expand "= new();"?

 

[Arved Sandstrom]

Yes, but, well, no. "What" also depends on one's point
of view, and perhaps my reply to Arved didn't take that into
account.

Many years ago I heard a (rather maudlin) sermon on this
topic, with a made-up anecdote: Fellow visits a construction
site and asks a worker what he's doing; "I'm mixing concrete."
Another worker says "I'm putting up a wall." A third says "I'm
building a cathedral."

They all described "what" they were doing, but from
different perspectives. A goal of writing good documentation
(in whatever form) is to anticipate the readers' perspectives.

That's exactly it. And if you were to ask "why" any of the worthies above
were doing what they were doing, they'd answer "so I can pay the bills" or
"because I enjoy working with my hands".

I'll accept Lew's definition, and I'll add that the large majority of all
comments I have ever seen in any language are "what" comments. Even with
well-written Java they help a great deal. I don't actually expect to see
many "why" comments unless the code is doing something somewhat unexpected
from the implementation standpoint. After all, why explain "why"? If the
chunk of code is doing what the low-level design demands there's no need to
put in a "why" comment.

To put it another way, if during a code review you ask the author "what" a
chunk of code is doing, it either means that their code is unclear and/or
the "what" comments are deficient. If you ask the author "why" the code is
doing what it's doing, the programmer will be scrambling for the design
document or explaining why he chose approach B rather than approach A to
satisfy the design goal. In the latter case I'd expect a "why" comment.

AHS

 

[Mark Space]

Sometimes I tire of typing code like

CleverGreenThing<WingNut, CorkScrew, BathTub> foo
= new CleverGreenThing<WingNut, CorkScrew, BathTub>();

I wonder if my IDE can (be trained to) expand "= new();"?

NetBeans already does most of this. If you assign to a type and type
"new" the first thing that comes up is the default constructor for that
type.

I haven't looked at generics specifically....

 

[Stefan Ram]

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.

If they follow a pattern, it can be put in a utility class and
be delegated to.

Getters and setters are questionable, because they break
encapsulation, and getters break "tell, don't ask".

Bar b = new Bar(x, y);
Why not
b = new Bar(x, y);

This would make such lines shorter, but add complexity to
the language, because there would be additional rules needed.

Programmers already can use Common Lisp and its macros to
get rid of all such repetitivness. When one uses Java, one
/has decided against this/. Then why complain? Why decide
to use a verbose language, then complain about its verbosity?

(For Lisp programmers reading this, I'm basically thinking of
defmacro)

If someone wants Lisp, he can use Lisp. We could modify Java
until it has become Lisp, but there is no need to do so,
because Lisp already exists. There even are Lisp and Scheme
implementations for the JVM.

 

[thufir]

While I fundamentally agree with you, Lew, there *are* places where Java
is painfully verbose. The amount of typing required for closures -
anonymous classes - is ridiculous compared to other languages.

Is there a technical reason Java can't use the Ruby approach to getter
and setter methods?


-Thufir

 

[Mark Space]

NetBeans already does most of this. If you assign to a type and type
"new" the first thing that comes up is the default constructor for that
type.

I haven't looked at generics specifically....

I just checked it. It does recognize the type parameter and it does
insert one for you.

List<String> lst = new // press ctrl-space here

And you get a pop up that includes AbstractList<String>,
ArrayList<String>(), etc.

 

[RedGrittyBrick]

I just checked it. It does recognize the type parameter and it does
insert one for you.

List<String> lst = new // press ctrl-space here

And you get a pop up that includes AbstractList<String>,
ArrayList<String>(), etc.

That is very handy.

I spent a few moments playing with Eclipse. If you type

new

and press Ctrl+space, (code completion) the top suggestion is "create
new object", selecting that replaces "new" with

type name = new type (arguments);

The cursor is positioned at the first character, as you type
"List<String>", that appears in both places in the template.
Not as good as Netbeans but worthwhile knowing about!



Having perused the "Tips and Tricks" section of Help in Eclipse I find
you can type

new ArrayList<String>();

then press Ctrl+1 (quick fix), the first suggestion is to "assign to new
variable" which changes the line to read

ArrayList<String> name = new ArrayList<String>();

Again, not quite as good as Netbeans IMHO. Either of these are slightly
more convenient for me than moving my hand to the mouse and using
drag-select Ctrl+C move click Ctrl+V. YMMV.

 

[Mark Space]

Again, not quite as good as Netbeans IMHO. Either of these are slightly
more convenient for me than moving my hand to the mouse and using
drag-select Ctrl+C move click Ctrl+V. YMMV.

NetBeans also has a macro facility that allows you to parse elements on
a line or in a file, and operate on them. For example, adding a
variable named the same as its type, just with a lower case letter.

Invoice -> Invoice invoice

Since NetBeans and Eclipse are so similar, I'm sure Eclipse has the
capability. You should be able to save even more typing.

Here's the NetBeans quick editing guide:

<http://www.netbeans.org/kb/articles/stop-typing-source-code.html>

 

[thufir]

In Ruby it's:

b = new Bar(x,y) #no semicolon

However, you can't do that in Java because Java is a compiled and
statically typed language, you need that interface option. So far as I
know, please correct me if I'm wrong!


and, for your getter/setters it's (I think):

attrib_reader :foo, :bar, :baz #"getters" only for these attributes

attrib_writer :x, :y, :z #"getters" and "setters" methods for
#these attributes


For the attrib_reader and attrib_writer, you don't have to actually
*write* the boilerplater getter setters. It would be awesome if Java
were to use something like attrib_reader!


Some of what you want is, so far as I know, impossible or pointless for a
compiled language like Java.


-Thufir

 

[thufir]

The important thing is that no programmer should ever use "too much
typing" as an excuse for anything. The important thing isn't the effort
of the original programmer's typing, but later maintainers' and ops
personnel's effort to read and maintain that code. Insistence on
shaving off a few dozen keystrokes at the expense of operations is a
false economy and actionable laziness.

It's not the typing, it's, for me, the un-necessary boiler-plate such as
getter setter methods (see Ruby).


-Thufir

 

[thufir]

Some languages have the concept of a mixin class. In Groovy and Ruby
they're literally called mixins; in C++, it's an application of multiple
implementation inheritance; in Objective C, they're called categories.
In all cases the effect is to add methods to a class by applying a
default implementation, which may be overridden when needed.

I didn't know that Groovy has mix-in's! Is it possible for Java to have
mix-in's?


-Thufir

 

[thufir]

Maybe you should see Ruby and just forget about Java.

Well, I can take a course in Java, but no local colleges offer Ruby (yet).


-Thufir

 

[thufir]

Yes.

What is the Ruby approach?

Something like:


attrib_writer :foo, :bar #getter and setter for foo and bar attributes,
#getter setter methods aren't actually written



-Thufir

 

[thufir]

Well, Java cannot do that because it's not in the language definition
and because the colon character already serves three other purposes in
Java.

That Ruby syntax doesn't work in Java isn't the point at all.

I would just go with getters/setters. What's the big deal? My IDEs
generate them for me, so there's no typing, and it sure helps
maintainers to see them.

It would be a huge waste of energy to retrofit Java with such a feature.

The point is that getter/setter methods are boilerplate. Adding such a
feature to Java would be worth it, and Java is constantly in flux.


-Thufir

 

[Arved Sandstrom]

Is there a technical reason Java can't use the Ruby approach to getter
and setter methods?

-Thufir

I myself think the Java approach is OK.

For starters, let's agree that the "effort" argument is nonsensical. A
modern IDE saves you all the typing.

The code bloat/readability argument has some small merit...not so much the
bloat, but the readability. Me, I just use the IDE to park the accessors out
of the way in a clearly labelled section of the class. In any case, with
IDEs you can easily jump to where you need to go.

The real issue is class design. Can you justify your getters and setters,
each and every one? Who needs to use them...the class itself, subclasses,
classes in the package, or everyone? How many setters (apart from say
private ones) do you need after you've carefully considered what
constructors make sense? Carefully choosing the class methods to maximize
the amount of work done *inside* the class cuts down on getters and setters
too.

We also cut down on accessors with a careful analysis of what the *logical*
class attributes really are. At a given moment a certain class may have 5
logical attributes, but 12 instance variables that implement those logical
attributes. Along with a number of constructors (hopefully knowing quite
little about those instance variables) and perhaps one or two value objects
for information passing (if truly required), there may be only 2 setters and
certainly no more than 5 getters. For example, a personName may only need
one getter (returning a String) but may have half a dozen private instance
fields to store its bits. Point being, the Ruby/C# approaches show off best
with a certain category of objects, quite simplistic ones.

AHS