[otj-users] Visibility rules

[Stephan Herrmann]

Hi,

Current work on migrating the OT/J compiler to Eclipse 3.4 has revealed that 
until now we are not consistently enforcing the rules for default visibility
as defined in OTJLD 1.2.1(e) 
	(http://www.objectteams.org/def/1.1/s1.html#s1.2.1.e).

I would like to take the opportunity to (once more) discuss these rules here.
Normally, visibility rules would be a rather boring topic to discuss,
but it is actually not trivial to define something that is convenient
for OT/J and blends well into the existing Java rules.

Wrt visibility, I see the following differences between OT/J and plain Java:
 * Along implicit inheritance role classes are more intimately connected than
   along explicit inheritance (this partly relates to the implementation
   using copy-inheritance). This is what motivates OTJLD 1.4(b):
	"Along implicit inheritance, the names of methods or fields may not hide,
	 shadow or obscure any previously visible name.
	 (see JLS §8.3, §8.4.6.2, §8.5, §9.3, §9.5 (hiding), §6.3.1 (shadowing),
	 §6.3.2 (obscuring)."
   As a result private members are also available in implicit sub-roles.

 * We need a visibility level that denies access to the enclosing team 
   and sibling roles - 
   such a level is missing from Java such that the following is allowed:
	public class O {
        	class I {
                	private int secret;
	        }
        	void foo(I i) {
                	System.out.print(i.secret); // LEGAL IN JAVA!!
	        }
	}
   This would mean that roles cannot be used as capsules within a team.

Given all that, I consider the following levels of visibility as usefull:

 (a) unrestricted: everybody may access such members

 (b) all within the same team: the direct enclosing team plus direct sibling
     roles may access such members

 (c) only this role

Item (c) is yet quite vague:

 * do we need a level that is hidden to explicit sub-classes (like private)?
   That would introduce a difference in the treatment of explicit vs. implicit
   inheritance. (currently this is the difference between private and <default>).

 * conceptually it would be very nice to interpret "this role" as the current *instance*.
   In that case, the following code would be illegal:
	protected class R {
		<only-this-role> void m() { ... }
		void foo(R other) { other.m(); } // <- not same instance.
	}
   Since Java does not support any instance-based visibility this might cause
   confusion for Java programmers learning OT/J.

Finally, it is not perfectly clear how the desirable levels map to the modifiers
public, protected, <default> and private.

While most of the above is not really in conflict with 1.2.1(e) some things
appear somewhat arbitrary. In contrast to 1.2.1(e) I currently feel that 
"all within the same team" should perhaps be the default (no modifier).

OTOH, strictly implementing 1.2.1(e) would probably break some existing code,
because <default> is defined to be more restrictive than currently enforced
(the test suite has numerous breakages if this rule is enforced). 

Officially opening the <default> visibility as mentioned above would avoid this problem.
In that case: what would be a good interpretation for "protected" ???
Or would three levels ((a)-(c) above) suffice ????
(We might consider deprecating "protected" for role methods/fields and 
meanwhile interpreting this identical to <default>? )

Would it be useful to define a visibility that grants access even into
nested roles but not to the world outside the top-most team? like this:
	public team class T1 {
		public team class Mid {
			public class R {
				<nested-access> String val;
			}
		}
		// arg m only needed for correct typing:
		void foo(final Mid m, R<@m> r) { System.out.print(r.val); } // legal
	}
	public class Alien {
		// args t and m only needed for correct typing:
		void bar(final T1 t, final Mid<@t> m, R<@m> r)  {
			System.out.print(r.val);  			// ILLEGAL??
		}
	}
Currently you have to choose between protected (both accesses are illegal) 
or public (both accesses are legal).
But perhaps such <nested-access> is actually overkill. 
Just playing around with what we have ;-)

Does any one have an oppinion on this legalese issue?

best,
Stephan