Re: Re: Visibility

> That's what I thought you meant.  Fields are, however, definitely
> attached to classes and are defined that way.  The obvious (for me at
> least) semantics for private in that situation is to restrict
> visibility to the enclosing scope.

However, the question is whether classes define scopes or not. It's equally 
simple to decide that modules define scopes, not classes. Both choices can be 
seen as consistent with Java, where (basically) there is only one toplevel 
class per file/module. And choosing private fields to be only visible inside 
the class would make it impossible to define some methods outside the class, 
which does not seem logical in a language with multi-methods (where one can 
see methods inside classes as a convenience only, not something essential).


It should also be easier to say that private limits visibility to the module, 
rather than to distinguish between methods and fields. And for people 
following closely the "java style" (methods inside classes), they won't even 
see the difference with Java on this aspect, so it should not be surprising.


>   package A;
>   // module A1;     // new keyword for header?
>   class a {
>     private int i;  // enclosing scope is the class
>   }
> 
> For simplicity perhaps the more radical suggestion of having each
> package definition in a single file and only public and package
> visibility.

I see a package as containing a (minimal) set of features (classes and 
methods) that provide a certain functionality. In some cases, having all of 
them in the same file would make the file too big. Being able to split a 
package into several files helps the internal organisation, while that 
organisation is hidden to public clients.


>  > In what language? In Nice all ambiguities are detected. I just tried this
>  > situation, you get the following error:
> 
> Ah, I see that I did have a default implementation... 

Thanks, you found a bug in an optimisation for dispatch tests. This is fixed 
in CVS. Aallow a few hours for the development version to be updated.


>  > I don't think there is a problem here. Dispatch on interfaces is
>  > not allowed at all in most languages (even with single dispatch).
> 
> A clarification please: are you suggesting removing interface-typed
> parameters from the dispatch calculation or disallowing method
> definitions which involve any interface-typed parameters?

Neither, only something much less restrictive: disallow _dispatch_ on 
interface types (only for non-public methods, that's understood).

For instance, with:

interface I {}
interface I1 extends I {}
interface I2 extends I {}

abstract class A implements I1 {} // or I2, or I
class B implement I1 {} // or I2, or I


// non-public method
void foo(I);

you can do all of these
foo(I x) { ... } // default implementation
foo(A x) { ... } // dispatch on an abstract class
foo(B x) { ... } // dispatch on a concrete class

but not dispatch on subinteraces of I
foo(I1 x) { ... } // illegal dispatch on I1
foo(I2 x) { ... }


As discussed before, the implementations could probably even be allowed if 
neither I1/I2 nor any of their subinterfaces is public.


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