atom feed15 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 
Subject:Re: accessibility proposal
From:Brian Goetz (Bria@Sun.COM)
Date:Jun 18, 2008 7:37:59 am
List:net.java.dev.openjfx-compiler.dev

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?

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>