[jsr294-modularity-eg] Pain

[David M. Lloyd]

On 08/10/2009 01:46 PM, Alex Buckley wrote:
> David M. Lloyd wrote:
>>> "A module is a named set of packages that a) defines an encapsulation
>>> boundary for its member types, b) describes its relationships with other
>>> named modules, and c) enforces both encapsulation and relationships at
>>> compile-time and runtime. A module is identified by a name and
>>> optionally a version."
>>> -http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000187.html 
>>>
>>> The whole point was to introduce a single concept for both 
>>> accessibility and visibility. I understand you want two concepts, 
>>> which would be more expressive, but also more complicated as I 
>>> outlined in mails up-thread.
>>
>> I'm probably missing something here, but why not simply broaden 
>> package-private access to be module-private, with an equivalent change 
>> to protected?  Then require that all modules' packages are "sealed" to 
>> avoid the split-package problem - or just ignore it and consider the 
>> in-module rules to be separate.  Packages outside of modules would 
>> conform to the old rules.  Problem solved, no language-level changes 
>> needed, no learning curve.
> 
> So there's no package-private access inside a deployment module anymore? 
> That's a retrograde step. Packages do a fine job and should not be 
> redefined.

No they don't, they are silly.  Anyway I'm not talking about redefining 
them at all, just extending the almost-useful package-private access level 
in a fully compatible and expected way.  After all, package-private is most 
commonly used in the JDK and most other projects I've seen to separate API 
and implementation; such a thing could be done even more effectively if you 
expand the notion of privacy across the whole module.  Why would one part 
of a module ever need to hide something from another part, but share it 
within the package within the module?  That use case makes no sense; it can 
never happen.

- DML