Re: Visibility

 > Is this visibility to be enforced by the JVM?  If yes, then what
 > mappings have you assigned?

It's not implemented yet, but the plan is to use JVM visibility as
much as possible.

With package (default) and public, the mapping is obvious. Private
would likely be more difficult to use, unless we change the way code
is compiled (which could be done is the long run).

 > > This would be the good time to hear ideas about the kind of
 > > visibility control is desirable. Is the private/default/public
 > > model good enough?
 >
 > local: can not be specialised outside the defining package even if it
 > can be called in that context - a modifier to the above visibilities
 > and not the default

Is this about methods?

It's possibly problematic to limit implementation of methods: what
happens if another package defines a new class for which no
implementation of the method is applicable? It could seem to be 
sufficient to require that non-public methods have a default 
implementation (since they are not public, ambiguities cannot be created 
in other packages). But actually, you can create an ambiguity by 
declaring a new class that implements two interfaces.

The reverse situation seems to be useful as well: do not allow some 
method to be called outside the package, but still leave open its 
implementation for such situations.

Daniel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click