Just Java Chapter-6: Why not cover all static data/methods/blocks/classes

On Page 114 of the sample chapter-6, I saw that Static Blocks and Static Classes will be discussed in other chapters... I just would like to know where they will be in the later chapters? I can guess that Static Classes would be in Chapter-12(Nested classes), but I can't find into which chapter Static Blocks topic can be fitted... Could you clarify a bit the reason(if there is) why you didn't try to cover all static data, static methods, static blocks and static classes into chapter-6, which is titiled as Static, Final and Enumeration Types?

If there is no particular reasons, it doesn't matter... I just would like to get to know about your writing style and technique... Thanks a lot...

Could you clarify a bit the reason(if there is) why you didn't try to cover all static data, static methods, static blocks and static classes into chapter-6, which is titiled as Static, Final and Enumeration Types?

Hi Ko Ko,

You raise a good point here, which is "how does a writer decide what to cover in a chapter"?

The answer is that it is a tradeoff with many competing elements. The two starting points
are that you know there is some amount of material relating to topic A that you want to cover.
And you know that readers cannot tolerate a chapter longer than a certain length, no matter
how interesting you try to make it.

So those represent the boundaries for the material - one pushing to get more in, and the
other pushing to keep it smaller and more manageable.

The chapters before this one cover most of the other elements in the Java type system, so I
knew that it was time to introduce enums. However, I had not covered static or final yet.
And since enums are final static objects, that was absolutely necessary groundwork, and in fact
a logical place to put them.

However, I certainly didn't want to bring in all the other uses of static too, like static imports,
static blocks, and static classes. They are not necessary to understand enums, and they
would balloon the chapter up in size. So you make a deliberate decision to postpone that
part of static, and just deal with the things people need to understand enums.

Every writer makes this kind of tradeoff (though they all make different decisions about
what to split off and to where). One of the ways to judge a book is to look not only at
what it covers, but also at how consistently it covers it, and in what order. Whenever I look
at a new programming language book, one of the first things I look for is an explanation of
associativity (assuming the language uses associativity to parse its expressions). This is a
topic that is often poorly understood and poorly explained. But it is *essential* for a proper
understanding of how expressions are evaluated. Try it! Pick up your favorite programming
book (not just Jave book) and look for the description of associativity!

Cheers,

Peter

Thanks a lot for your kind explanation about the technique of technical books writers... It's very knowledgable and I hope others also will benefit from this thread...

Are the rest of Static Imports, blocks and classes dicussed in Nested Classes chapter of the book? But the new feature of Tiger, Static Imports, seems that it does not fit into any chapters in the book... Is it in chapter-8(More OOP-Extending Classes)? Or am I missing sthing?

Ko Ko, where did you find the sample chapter? I would like to read it.

Please see this thread

Originally posted by Siripa Siangklom:
Please see this thread

Thanks Siripa. Man, I have read about static and I knew what it was and what is was used for, but never have I read such a simple plain powerful description of it like what is in chapter 6. Well done Peter!

Originally posted by Gregg Bolinger:


Thanks Siripa. Man, I have read about static and I knew what it was and what is was used for, but never have I read such a simple plain powerful description of it like what is in chapter 6. Well done Peter!

Gregg,
I also find the chapter really good... Have a look at some great portions from that chapter...

A common pitfall with static methods
A common pitfall is to reference per-object members from a static method. This
�does not compute�. A static method isn�t invoked on an object and doesn�t have
the implicit �this� pointer to individual object data, so the compiler won�t know
which object you want. You�ll get an error message saying �Can't make static
reference to non-static variable.�

I even sometimes did such error... But the chapter reminds me again of such error... That's cool...

The following is kinda nice comment on the word "final", while Peter did a great comment on the word "static" in the previous section of this "final" section... I even discussed with Peter in this thread about the word "static"

This section looks at final, which makes something constant. Why was the word
�const� or �constant� not chosen? Because �final� can also be applied to methods,
as well as data, and the term �final� makes better sense for both.

And last but not least, I didn't know the following code is legal... Sometimes we overlook the tiny things...
void someMethod(final MyClass c, final int a[]) { c.field = 7; // allowed a[0] = 7; // allowed c = new MyClass(); // final means this line is NOT allowed a = new int[13]; // final means this line is NOT allowed }
Peter said that "Programmers rarely use this, because it clutters up the signature and makes the
parameter names harder to read."...

Anyway, I just would like to share the knowledge that I got from the sample chapter. At least I can taste his writing style and it's excellent... I do cheer for Peter's book to win Best Java Book of 2004 as well...