[jsr294-modularity-eg] Pain

[Peter Kriens]

> ... that's a very specific, easy-to-reason-about extension point in  
> the language's accessibility model.
There is nothing to reason about because the module membership is  
opaque ... I guess at a certain level this is "easy". :-)

Kind regards,

	peter Kriens


On 25 jul 2009, at 01:40, Alex Buckley wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090728/006c278c/attachment-0001.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg