Re: Protected

> I wonder it might be feasible to make a keyword that restricts access on a 
> package basis, rather than a per file basis, such that methods outside the 
> package cannot get access to certain methods and variables, but methods 
> inside the package can.

I presume there will a package-level visibility, but it won't replace 
the "protected" keyword. With "protected" i can design a "library" 
package whose classes can be extended by the end users. I can extend 
classes even without having the source code of a package whose classes 
i'm extending (or having a license restriction to modify the extended 
package, or just being lazy to modify an actively developed package 
every time it is updated, whatever).

When it comes to methods, i suggest that "protected" visibility (being 
the default one!) allows to override/extend the method. This is the 
current behaviour anyway (all methods being implicitly public).

For fields, protected visibility (again, being the default one) should 
allow field access to any method wich have the class in question as one 
of its arguments...

package a;
class Foo {
   String s1; // protected
   private String internal;
}
class Bar {
   String s2; // protected
   private String internal;
}
void doSomething(Foo foo, Bar bar){
   println(foo.internal); // ok, private access
   println(bar.internal); // ok, private access
}

package b;
override void doSomething(Foo foo, Bar bar){
   foo.s1 = "value"; // ok
   bar.s2 = "value"; // ok
   println(foo.internal); // compile-time error
   println(bar.internal); // compile-time error
}


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf