How does this Code work?

[anthony]

I came across a some code in a program, the program runs fine but the
syntax of one line is a little strange.

grid.new DataGenerator().start();

The DataGenerator is a timer whos class is in the same file as the grid
class.

I would like to Stop the timer at some point but I don't know how to
reference it when it was created like this?

so,
1. Why does this line even work? (where can I find a description of
this syntax?)

2. How can I reference DataGenerator.stop

Thanks

 

[Oliver Wong]

I came across a some code in a program, the program runs fine but the
syntax of one line is a little strange.

grid.new DataGenerator().start();

The DataGenerator is a timer whos class is in the same file as the grid
class.

I would like to Stop the timer at some point but I don't know how to
reference it when it was created like this?

Hmm, I've never ran across this syntax before, but did you try something
like:

DataGenerator myGenerator = grid.new DataGenerator();
myGenerator.start();

so,
1. Why does this line even work? (where can I find a description of
this syntax?)

Looks like DataGenerator is an inner class of grid. So you're making a new
instance of DataGenerator from the given grid object, and then immediately
calling start() on it.

2. How can I reference DataGenerator.stop

If you use the two lines above and they work, you can use
myGenerator.stop();

- Oliver

 

[Thomas Hawtin]

I came across a some code in a program, the program runs fine but the
syntax of one line is a little strange.

grid.new DataGenerator().start();

The DataGenerator is a timer whos class is in the same file as the grid
class.

Yup, it will probably be an inner member class, rather than just a plain
nested class. That means it will have an implicit reference to the outer
class. Therefore when constructed it will need to know what to fill the
implicit reference with. Usually that is the this (or outer this) of the
constructing method. However you can supply a different value, as here.

In eight years of Java programming, I don't remember using it once.

I would like to Stop the timer at some point but I don't know how to
reference it when it was created like this?

Use

Timer timer = grid.new DataGenerator();
timer.start();
....
timer.stop();

It is, very broadly speaking, a bad idea to invoke new and immediately
call a method on that object, rather than storing the reference in a
variable.

1. Why does this line even work? (where can I find a description of
this syntax?)

JLS 3rd Ed, last bullet of p426 in Section 15.9.2 Determining Enclosing
Instances:

"Otherwise, the class instance creation expression is a qualified
class instance creation expression. The immediately enclosing instance
of i is the object that is the value of the Primary expression."

A couple pages back it gives the (badly wrapped) grammar rule

ClassInstanceCreationExpression:
Primary. new TypeArguments(opt) Identifier TypeArguments(opt)
( ArgumentsList(opt) ) ClassBody(opt)

Clear? Looks as if you can't qualify the type, which is a new one on me.

Tom Hawtin

 

[jan V]

I came across a some code in a program, the program runs fine but the

syntax of one line is a little strange.

grid.new DataGenerator().start();

Ha.. inner classes obfuscation again.

Don't worry too much about it. The original author of that piece of "let's
test how well you know the Java language spec" code clearly doesn't give a
hoot about program readability. By all means check the spec to learn the
minutiae of inner classes, but the important lesson to take away from this
statement is that you should never code anything like this yourself. A good
programmer always writes readable code... code which never becomes the
subject of a newsgroup posting with a subject "What does this mean?"

 

[Roedy Green]

I would like to Stop the timer at some point but I don't know how to
reference it when it was created like this?

You would have to break that line up so you have a handle on the timer
something like this

grid.DataGenerator t = grid.new DataGenerator();
t.start();

 

[Roedy Green]

It is, very broadly speaking, a bad idea to invoke new and immediately
call a method on that object, rather than storing the reference in a
variable.

Why is that? If you have no intention of ever using the object again,
all you are doing is delaying the GC with the long syntax.. The short
syntax makes it clear you never intend to use it again. That speaks
speak in favour of the abbreviated syntax.

I can see one reason for the long syntax. If you change your mind and
want to use some other methods later, it is easier if you have a
handle on it.

 

[Roedy Green]

Don't worry too much about it. The original author of that piece of "let's
test how well you know the Java language spec" code clearly doesn't give a
hoot about program readability. By all means check the spec to learn the
minutiae of inner classes, but the important lesson to take away from this
statement is that you should never code anything like this yourself.

On the other hand, if you are going for Java certification or a
teaching job at Developmentor, you need to this trivia.

Many years ago I saw a COBOL exam that asked all kinds of detailed
questions about the IDENTIFICATION-DIVISION. My response was, anyone
who knew the answers was unqualified. Any sane programmer cuts and
pastes that stuff with barely a glance at it. Only a ninny would
write it out afresh each time.

Similarly people who know too much about the intricacies of Java
syntax are liable to write code that only fellow nerds can decipher.

The greatest virtue is to understand it all, but refrain from using
the tricky stuff except when absolutely required.

 

[anthony]

Thanks for the suggestions, I got it to work the way I want it.

 

[Thomas Hawtin]

Why is that? If you have no intention of ever using the object again,
all you are doing is delaying the GC with the long syntax.. The short
syntax makes it clear you never intend to use it again. That speaks
speak in favour of the abbreviated syntax.

You and your extremely premature optimisation. (Not that I am against
arbitrary idioms chosen because they are performance-safe.)

My issue with it is that it tends to indicate poor design. If you create
an object and than just call a method on it, what was the point of
exposing the functionality as an object. Why not just provide a static
method?

OTOH, fixing the symptoms wont help the design.

The operator precedence is a little obscure. But then again, it wouldn't
stop me using it with classes such as StringBuffer, that return this
from their builder methods.

I can see one reason for the long syntax. If you change your mind and
want to use some other methods later, it is easier if you have a
handle on it.

Certainly that is often the case with, say, Thread. Simplistically you
want to create a Thread and start it. However, you should soon want to
call, say, setPriority on it, which means changing your code. A good
maintenance coder will add an instance initialiser*.

Tom Hawtin

*You can add your own favourite smiley.

 

[Thomas Hawtin]

Don't worry too much about it. The original author of that piece of "let's
test how well you know the Java language spec" code clearly doesn't give a
hoot about program readability. By all means check the spec to learn the

It's not the original author's attitude to readability I particularly
worry about. It's obscure, but not unreadable syntax. What worries me is
the attitude towards design. You are providing an implicit and intimate
relationship between two objects, but you are doing it outside of both.
That's probably why the syntax is little used.

minutiae of inner classes, but the important lesson to take away from this
statement is that you should never code anything like this yourself. A good
programmer always writes readable code... code which never becomes the
subject of a newsgroup posting with a subject "What does this mean?"

Drivel. Without going back and doing an analysis, most of the "I don't
understand?" postings are about bog standard stuff.

Tom Hawtin

 

[Roedy Green]

You and your extremely premature optimisation. (Not that I am against
arbitrary idioms chosen because they are performance-safe.)

It in not premature optimisation it is making the code READABLE.

there is no point is using a slow form when the slow form is LESS
readable.

You often act is if writing SLOW code is some sort of virtue in its
own right because it proves your disregrard for optimisation.

There is no reason to postpone optimisation that improves readability.

 

[jan V]

minutiae of inner classes, but the important lesson to take away from
this

Drivel. Without going back and doing an analysis, most of the "I don't
understand?" postings are about bog standard stuff.

If "A good programmer always writes readable code... " is drivel to you,
then it may explain why you're still unemployed.

 

[Thomas Hawtin]

[Tom Hawtin wrote: ]

[jan V wrote: ]

programmer always writes readable code... code which never becomes the
subject of a newsgroup posting with a subject "What does this mean?"

Drivel. Without going back and doing an analysis, most of the "I don't
understand?" postings are about bog standard stuff.

If "A good programmer always writes readable code... " is drivel to you,
then it may explain why you're still unemployed.

You don't think that just perhaps I might have been referring to '...
code which never becomes the subject of a newsgroup posting with a
subject "What does this mean?"'.

Tom Hawtin