|Per Bothner||Jun 16, 2008 4:22 pm|
|Robert Field||Jun 16, 2008 9:49 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:38 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:57 pm|
|Dean Iverson||Jun 18, 2008 1:22 pm|
|Brian Goetz||Jun 18, 2008 1:26 pm|
|Christopher Oliver||Jun 18, 2008 2:10 pm|
|Subject:||Re: accessibility proposal|
|From:||Brian Goetz (Bria...@Sun.COM)|
|Date:||Jun 18, 2008 7:38:22 am|
While compatibility with Java is an important goal, let's not lose sight of the fact that Java developers are decidedly *not* the target audience for JavaFX Script. What's good for Java developers may not necessarily be good for JavaFX developers.
The ways in which these proposals differ is in subtle ways. In fact, I'll bet that many java developers would be surprised to learn what "protected" really means in Java. Even language experts get confused on these points. So while compatibility is a valid goal, so is simplification.
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". An inner class member declared as private can still be accessed by its enclosing class, for example. 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?
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.
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>