Motivation for type-level exports

[David M. Lloyd]

On 11/03/2011 06:35 PM, Jesse Glick wrote:
> Not an official response but my guess:
>
> On 11/03/2011 06:20 PM, Neil Bartlett wrote:
>> It seems that the only possible need for type-level exports could be
>> one or both of the following:
>
> 3. To permit the type to be visible to other packages in the same
> module, but not to other modules. In my experience this is a rather
> common need. If only package-granularity exports are available, you can
> still get around this, but it is tricky, requiring a special trampoline
> [1]. A new access modifier intermediate between public and default would
> be more intuitive, I think.
>
> [1] http://wiki.apidesign.org/wiki/FriendPackages

I think you're confusing the issue of visibility with accessibility.

Your #3 is accommodated via a new access level - "module" - which would 
restrict *accessibility* of a class but not *visibility* of that class. 
  Given the presumed availability of the new module-wide access level, 
your #3 is satisfied wholly, yet Neil's question is unanswered.

Leaving aside the unmitigated disaster that inevitably awaits us in 
regards to the location and disposition of module metadata in the 
current prototype, exports (or rather the lack of them) are generally 
more useful in avoiding linkage problems than as a security mechanism. 
But our experience has shown that controlling exports at a package level 
is more than adequate for this task for what we expect to be a typical 
module library distribution.  We've only needed to add hooks for 
type-level visibility controls for the purposes of our OSGi implementation.
-- 
- DML