 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
15 messages in net.java.dev.openjfx-compiler.devRe: accessibility proposal| From | Sent On | Attachments |
|---|---|---|
| Per Bothner | Jun 16, 2008 4:21 pm | |
| Robert Field | Jun 16, 2008 9:48 pm | |
| Joshua Smith | Jun 16, 2008 10:24 pm | |
| Rémi Forax | Jun 17, 2008 12:57 am | |
| Ethan Nicholas | Jun 18, 2008 6:40 am | |
| Brian Goetz | Jun 18, 2008 7:37 am | |
| Shannon Hickey | Jun 18, 2008 7:44 am | |
| Brian Goetz | Jun 18, 2008 8:05 am | |
| Robert Field | Jun 18, 2008 9:32 am | |
| Per Bothner | Jun 18, 2008 12:16 pm | |
| Dean Iverson | Jun 18, 2008 12:51 pm | |
| Brian Goetz | Jun 18, 2008 12:56 pm | |
| Dean Iverson | Jun 18, 2008 1:22 pm | |
| Brian Goetz | Jun 18, 2008 1:26 pm | |
| Christopher Oliver | Jun 18, 2008 2:09 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: accessibility proposal | Actions... |
|---|---|---|
| From: | Rémi Forax (for...@univ-mlv.fr) | |
| Date: | Jun 17, 2008 12:57:25 am | |
| List: | net.java.dev.openjfx-compiler.dev | |
Per Bothner a écrit :
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.
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...)
you're wrong :) see section 8.3.3.2 of JLS3. field hidding is not related to accessibility modifiers (private, etc).
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.
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.
Rémi