Alex.Buckley at Sun.COM
Fri Jul 24 19:40:25 EDT 2009
Richard S. Hall wrote:
> It seems somewhat defeatist to just resign ourselves to the fact that we
> need a design-by-committee, meta-ish approach. I agree with Peter's
> overall goal of trying to be more concrete. The trick is keeping it
> small, while leaving room for module systems to do their own thing.
I agree they should do their own thing w.r.t. visibility; for
accessibility, the language's model must be kept as simple as possible.
> From what I understand about Peter's proposal, he suggests agreeing upon:
> * Defining packages to be either public, module, or private.
> * Defining dependencies to be either "normal" or "implementation"
> (where module-level dependencies are mapped down to package
> o "normal" sees only public types in public packages.
> o "implementation" sees public and module types in public or
> module packages.
> I think this sounds reasonable.
As a model of accessibility - forgetting about nesting and containers -
it's rather complicated to embed in the language. Every combination of
package-wide accessibility + dependency type + type accessibility has to
be understood. Add back nesting and a module system's constraints on
visibility, and it's a den of complexity.
> The "hook" for module systems is when the container is created, the
> various module systems can map the above constructs into their own
> approach, which can have their own ugly semantics as far as things like
> class loaders are concerned (e.g., whether it is loaded by different
> class loaders or the same, the actual search policy, etc.).
So we're back to language constructs being deeply governed by
non-language mechanisms! That's a bad thing. Right now, we have only
module-private accessibility being controlled by the host system (since
it governs module membership) ... that's a very specific,
easy-to-reason-about extension point in the language's accessibility
model. It was also the clear will of the EG.
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer