Re: Visibility

On Sun, 20 Mar 2005, Daniel Bonniot said:
 > It's not implemented yet, but the plan is to use JVM visibility as
 > much as possible.

Surely JVM visibility must support *all* of the Nice visibility
semantics?  Otherwise there's the danger of Java code subverting,
deliberately or not, Nice visibility.

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

Given that Nice methods are associated with packages rather than
classes what meaning are you attributing to "private"?  Private makes
more sense for fields but then there'd be no method which could access
them.

 >> 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?

Yes.  I see it as corresponding somewhat to Java's "final", so there's
likely a mixture of good and bad points around providing it.  I
mentioned it mostly because it can be enforced with JVM visibilities,
by stopping Java code from sub-classing the method's dispatcher class.

 > 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?

Then that class doesn't and can't conform to the method contract and
thus is invalid.  Harsh and paranoid but then marking some method as
"local" is all about paranoia.

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

Sorry, lost me there.  What aspect of (multiple-inheritance based?)
ambiguity here affects the visibility?

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

Useful but not the default?

Seems difficult to implement with JVM semantics.  Package A has a
package scoped method and package B imports A and adds an
implementation of that method.  Which package owns that implementation
at the JVM level?  If it's B then the dispatcher in package A can't
see it, but if A owns it then that's a security hole and A can't be
deployed in a standalone jar.

Maybe visibilities don't work for the dispatcher itself but instead
some sort of dispatcher registry so that package B can ask package A
to access its dispatcher first (which can dispatch to the method in
package B but has no special privileges in A) and fall-back to the
dispatcher in A.

I'll add further ramblings to the wiki.

Rohan

-- 
[email protected]          |   1 + 1 = ?        
                              |   a) 2     b) 10     c) Succ Succ Zero



-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click