 | 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: | Brian Goetz (Bria...@Sun.COM) | |
| Date: | Jun 18, 2008 12:56:40 pm | |
| List: | net.java.dev.openjfx-compiler.dev | |
I think that's Java-think talking; we're used to the way you have to do it in Java. Binding makes 90% of the MVC code just go away, which means that your model and view classes are much simpler, and putting them together is often more natural.
You are right that it would be nice to have finer-grained access control, and we are considering such things for a later version. But also keep in mind that more control means complicating the user model and making the language harder to learn. What we have suggested here embodies tradeoffs that favor simplicity.
Dean Iverson wrote:
And will the definition of "unit" remain the current file? I think it will be fairly common for people to write their GUI code in terms of models and views. It would be nice if there was a way to specify that certain attributes are only visible between the model and view classes without having to put the classes in the same file.
Dean
On Jun 18, 2008, at 10:32 AM, Robert Field wrote:
Ethan Nicholas wrote:
It sounds like they do not line up. "private" in Java does not mean "only accessible by this class", it means "only accessible from within this compilation unit".
Errr..., not actually
An inner class member declared as private can still be accessed by its enclosing class, for example.
Right, anywhere in the enclosing class, but, in Java, not in other parts of the compilation unit [let's, for this email, call it "unit"].
As I'm reading the proposal, the default accessibility is equivalent to Java's private, and JavaFX's private is "even more private". The other levels (aside from public) don't match either.
I second Joshua's opinion -- is there a specific reason why the access modifiers shouldn't work exactly the same way they do in Java?
I think the two are highly analogous. Remember that a difference between Java and JavaFX is that the smallest and primary grouping of classes is the package; while for JavaFX it is the unit (we have been calling this "module", but with Java modules on the horizon, that would be a very confusing name). The biggest difference is the substitution of unit for package:
*Java* *JavaFX* *public* anywhere anywhere *protected* subclasses and the package subclasses and the unit */default/* the package the unit *private* within the body of the top-level class within the class or nested classes
Other than unit vs package, the only difference is in private. Brian and I have both been quite frustrated by Java's not-very-private private. In JavaFX, places where you might want the loosy-goosey private of Java, would more naturally be handled by the default, unit-level, access. Except in nested classes, which, because of units, will be much less common in JavaFX, the difference will be rarely seen
-Robert
Ethan Nicholas eth...@ethannicholas.com <mailto:eth...@ethannicholas.com>
On Jun 17, 2008, at 1:24 AM, Joshua Smith wrote:
If Java FX is going to have scope that uses the same keywords as Java (public, private, protected and default (without a keyword)), then I think the keywords should be the same as Java. While Java FX Script is it's own language, we can't fool ourselves. The designers will use tools and won't care about scope. The developers will write code and assume that the scope rules are the same as Java.
I wasn't able to tell from the description below whether the defined scopes line up. If they do, great. But if not, I think it will be a source of confusion.
Also, one thing that has always bothered me about Java (while studying for SCJP or trying to mentor junior developers) is the default scope. It falls in the category of "the artist formally known as". No one knows how to refer to it. Let's give it a name. Even if it's the default scope, let's give it a name so that it can be referred to. In my opinion, we should have private, package-private, protected and public in Java even if the package-private keyword is unnecessary and is the default. At least it gives the scope a descriptive name.
So, in short, be consistent with Java or use different keywords and name all scopes, even the default scope.
Just my 2c.
Joshua Smith
On 6/16/08, *Per Bothner* <Per....@sun.com <mailto:Per....@sun.com>> 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.
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.
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. -- --Per Bothner per....@sun.com <mailto:per....@sun.com> pe...@bothner.com <mailto:pe...@bothner.com> http://per.bothner.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-...@openjfx-compiler.dev.java.net <mailto:dev-...@openjfx-compiler.dev.java.net> For additional commands, e-mail: dev-...@openjfx-compiler.dev.java.net <mailto:dev-...@openjfx-compiler.dev.java.net>