[jsr294-modularity-eg] Pain

[Alex Buckley]

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
>       dependencies)
>           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.

Alex
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg