[jsr294-modularity-eg] Pain

[Paul Benedict]

Maybe the problem is with the definition:

"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."

I notice both A and B are definitions, but C is activity (enforcement).
Could this be an ample source of confusion? Shouldn't the entire definition
of a module be a definition?

Paul

On Mon, Aug 10, 2009 at 1:46 PM, Alex Buckley <Alex.Buckley at sun.com> 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.
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090810/69762ce3/attachment.html>