15 messages in net.java.dev.openjfx-compiler.devRe: accessibility proposal
FromSent OnAttachments
Per BothnerJun 16, 2008 4:21 pm 
Robert FieldJun 16, 2008 9:48 pm 
Joshua SmithJun 16, 2008 10:24 pm 
Rémi ForaxJun 17, 2008 12:57 am 
Ethan NicholasJun 18, 2008 6:40 am 
Brian GoetzJun 18, 2008 7:37 am 
Shannon HickeyJun 18, 2008 7:44 am 
Brian GoetzJun 18, 2008 8:05 am 
Robert FieldJun 18, 2008 9:32 am 
Per BothnerJun 18, 2008 12:16 pm 
Dean IversonJun 18, 2008 12:51 pm 
Brian GoetzJun 18, 2008 12:56 pm 
Dean IversonJun 18, 2008 1:22 pm 
Brian GoetzJun 18, 2008 1:26 pm 
Christopher OliverJun 18, 2008 2:09 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: accessibility proposalActions...
From:Robert Field (Robe@Sun.COM)
Date:Jun 16, 2008 9:48:38 pm
List:net.java.dev.openjfx-compiler.dev

Per Bothner wrote:

Here is my summary of the compiler team's thinking on accessibility of class members. Please let us know of any concerns with this sketch:

A member of a class or a "module class" (compilation unit) may be a function, attribute/variable, or a class. The "accessability" of the member determines who can reference the member. The most common options are: * The default access is visible within the current compilation unit (module), but not in any other code. + "public" - everywhere visible, as in Java.

In addition, it seems useful to allow private and protected, mainly for compatibility and/or because people expect it: + 'private" - means only visible in the containing class (and classes nested within the containing class). + "protected" - visible in subclasses.

And the compilation unit.

That leave out a lot of detail ...

If class A has an attribute m, and B extends A, what happens if B also declares m? Do these clash, or is A.m "hidden" from B? In Java a field A.m is hidden from B if and only if m is declared as private - overwise (correct me if I'm wrong...) declaring an m in B is an error. If B.m is a non-private method with the same signature as A.m, it overrides A.m. It seems reasonable to have the same behavior in JavaFX.

If the class A is "compound" (can support multiple inheritance), then we can't make use of the JVM access controls, not even for private. Hence for B.m to not conflict with a private A.m the name of the latter needs to be "mangled".

In Java a protected member can be accessed not only from a subclass, but also from any class in the same package. The JavaFX "equivalent" would be to allow access from other classes in the same compilation unit, but this is an issue we might want to re-consider.

Because it is likely that you would want both subclass and compilation unit access, and the the later is the default and thus not explicitly specifiable there would be no way to declare both. I don't think there is anything to reconsider.

In Java the rules for protected are somewhat complicated (see JLS 3rd edition section 6.6.2). These rules guard against some questionable uses, but for JavaFX I don't think they're worth the extra complication.

A separate issue is what kind of access is allowed: for example, it would be nice to be able to declare that an attribute can be read but not assigned to. We don't yet have a proposal for that.

Actually, we do. You are forgetting about "controlled". "controlled" says that write access is limited to the compilation unit.

-Robert