Re: Re: Visibility

> Interesting!  In that case there's special protection in the JVM from
> "package injection" so external malicious code will still be thwarted.

Can you give a reference about this?

Doesn't this mean that if we need to turn some private into package we could 
get the same protection?

>  > Such rules enforced at the source level only are still useful, not from a
>  > security point of view but from a software engineering one.
> 
> Agreed.  Perhaps such visibility modifiers should avoid names which
> could be misconstrued as strong statements about the security
> provided.

Let's wait and see if this situation arises at all. It seems we might be able 
to enforce full safety.

>  >> 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.
> 
>  > private would restrict visibility to a single "module". (Typically
>  > a module is a source file
> 
> I wonder if the additional complexity is worthwhile.  There's still a
> disjoint between fields, scoped to the class, and methods, scoped to
> the module - perhaps the 'private' keyword should be replaced by
> 'module' or some other term to avoid confusing existing Java
> programmers.

No, my idea is that private would always be scoped to the module, for fields 
as well. It would be somewhat contrary to the Nice feel to assign such meaning 
to  classes, and in particular to make a difference between methods defined 
inside and outside the class (in the same module).


>  > If a module contains only one class, then we could use that class
>  > to put the methods of the module, which would also allow to enforce
>  > private fields. (we could even reject modules that define several
>  > classes with private fields, to guarantee we always enforce privacy
>  > at the bytecode level)
> 
> Which moves closer to one class plus attendant private-field accessing
> methods per module.

Actually, I suppose it can be useful to define two classes in the same module, 
with access to each others' private fields ("friend classes"). So maybe we 
shouldn't enforce one class with private fields per module as a rule, but just 
use it when it arises to optimize the compilation and avoid accessor tricks.

>  >> 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.
> 
>  > What do you mean by "the method's dispatcher class"?
> 
> The class in which the method's dispatcher method resides.  Sorry, it
> appears that some of my ruminating on avoiding code jumping past the
> dispatcher and calling implementations directly (by making the
> implementations visible only to the dispatcher) has affected my memory
> of the current situation... specifically that dispatcher methods are
> static.

Yes, that got me confused.

>  > Could you give some motivations why "local" would be useful? Concrete
>  > examples?
> 
> Not at present.  Your argument, especially the example where just
> importing two packages can cause a compiler error, has convinced me
> that this particular suggestion should be dropped.

Hum, but I also proposed a restriction which prevents this problem. Anyway, 
the situation arises without local/final, with non-public methods.

I think in a first step we can do without local/final, but I'm open to 
arguments for and against it. It seems possible to support it, the question is 
whether it's desirable.

>  > Here is the potential problem:
> 
>  > package p1;
>  > interface I {}
>  > interface I1 extends I {}
>  > interface I2 extends I {}
> 
>  > private String foo(I);
>  > foo(I1 i1) = ...;
>  > foo(I2 i2) = ...;
> 
>  > package p2; import p1;
>  > class A implements I1,I2 {}
> 
>  > // ambiguity about foo(new A())
> 
> Is this ambiguity detected?  I tried a similar diamond inheritance
> problem and found that one of the implementations was chosen (at
> random at compile time).

In what language? In Nice all ambiguities are detected. I just tried this 
situation, you get the following error:

   The implementation test failed for method java.lang.String foo(I):
   ambiguity for parameters of type (p2.A)


>  > If foo was public, you could solve the ambiguity in p2.
> 
> How?  Is there support for specifying which parent branch to search
> first?

foo(A a) = super(I2);


>  > With the restriction of no dispatch on interfaces for non-public
>  > methods, this case is ruled out.
> 
> Maybe the weaker restriction of no dispatch on *public* interfaces in
> non-public methods?

Yes, we can try to find weaker restrictions. For this one: what if a 
non-public interface has a public subinterface? (one could detect that 
situation since the subinterface must be in the package)

> Disallowing diamond inheritance would be another option.  Which is
> more useful I don't know.

I do think multiple-inheritance of interfaces is a good thing.

I don't think there is a problem here. Dispatch on interfaces is not allowed 
at all in most languages (even with single dispatch). Limiting it to public 
methods does not seem overrestrictive, and we can probably even partly lift 
that restriction.

Thanks for the discussion, it helps a lot figuring out what the design space 
is. I think a quite satisfactory solution is emerging.

Daniel


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click