Tor Iver Wilhelmsen skrev:

Well-quoted, Meister Wilhelmsen.

The writers of the Java specification did indeed make a mistake with
their first draft, as they themselves have now recognised.

Hierarchical decomposition of system behaviour is a singularly powerful
design aid. As Sun's Victoria Livschitz said, "The power of intuitively
understanding the meaning and relationship between things is the
proverbial silver bullet, if there is one, in the war against
complexity:"
http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html

And what is a more intuitive aid to comprehension than having
subpackages relate to their parents more than they relate to more
distant packages, precisely the opposite of the current JLS text?

For example, given the following package structure, a good designer
will clearly identify the software in com.game.view.gui as being more
related to the software in com.game.view than the software in
com.game.model.player:

com.game.model;
com.game.model.rules;
com.game.model.player;
com.game.controller;
com.game.view.gui;
com.game.view.html;

This is simply because the software in the view subpackages all relate
to presenting the game view, whereas the software in the model
subpackages relate to the game's playing behaviour. When the new
requirement pops up there the game should have an ascii-picture view
for old, text consoles, the designer will immediately think that most
of the work will be in the view subpackage somewhere, and not in the
player subpackage.

In other words, the hierarchical subpackages under the view package
represent a clearly identifiable encapsulation unit which is larger
than a package but smaller than the system as a whole. There is not,
however, an access modifier associated with this encapsulation unit, as
you correctly pointed out.

At least, not yet.

Gilad Bracha, JLS author, submitted JSR 277 for certification, and it
has zipped along at the usual JSR-process speed of around 2 milimetres
per year; this has led to JSR 294. One of Gilad's initial intentions
was precisely to introduce this
greater-than-package/less-than-system-wide encapsulation level (though
in trying to emulate .NET's deployment-based access modifier they,
IMHO, are taking a bit of a tangent):
http://blogs.sun.com/gbracha/entry/developing_modules_for_development

And a short summary of JSR itself:
http://jcp.org/en/jsr/detail?id=294

Bring on Java 7.

.ed

--

www.EdmundKirwan.com - Home of The Fractal Class Composition