Re: Visibility

>>  > 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?
> 
> 
> 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())
> 
> If foo was public, you could solve the ambiguity in p2. With the 
> restriction of no dispatch on interfaces for non-public methods, this 
> case is ruled out.

To me it is seems natural for module-visible methods (private ones) to 
be completely invisible outside of the module. That is, when trying to 
invoke foo(A) in the above example, the absence of method "foo" is 
reported, instead of ambiguity. Package p2 is allowed to implement it's 
own versions of foo(I1), foo(I2) and foo(A), private method foo defined 
in another module just doesn't interfere with this in any way.

This will allow for a safe definition of module-visible helper functions 
  within a large package without a risk that the same name is used 
somewhere else. (Namespaces where originally introduced to C++ to solve 
this name-clashing problem).


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