Statements before super()
in [Java Programming]
|
From: Thomas Pornin on 12 Feb 2010 04:43 According to markspace <nospam(a)nowhere.com>: > True, but something like this should be acceptable, imo: > > class MyClass extends YourClass > { > public MyClass(int i) > { > if ( i > 0) > { > super(i); > } else > { > super(); > } > } > ... Actually it would be acceptable to the JVM. The JVM enforces a call to a superclass constructor (only one call allowed) before accessing members; it does so with a control-flow analysis which is very similar to the analysis which figures out types for local variables, and whether local variables may be accessed before being initialized. If your code could be translated to bytecode then things would work. But the Java compiler enforces the JLS rules, which basically guarantee that whatever the compiler accepts will also be accepted by the JVM. This is not a strict equality: in that matter, the JLS is stricter than the JVM rules. The bright side is that what you suggest would require only some changes to the compiler, not the JVM and standard classes, and it would be backward compatible with existing, deployed JVM. --Thomas Pornin
From: Pitch on 12 Feb 2010 06:28 In article <hl1ao6$i80$2(a)news.albasani.net>, noone(a)lewscanon.com says... > > mscottschilling(a)hotmail.com says... > >> Suppose the call to "super()" needn't be the first line of a constructor. > >> Discuss the effect and/or legality of the following code: > >> > >> class MyClass extends YourClass > >> { > >> public MyClass(int i) > >> { > >> if ( i > 0) > >> { > >> super(i); > >> } > >> } > >> ... > > Pitch wrote: > > If you look at super() as just another method call it's perfectly ok. > > Constructor calls are not method calls. So that won't work. No it won't, but if is was a method it would. -- stirr your cofee properly
From: Pitch on 12 Feb 2010 06:32 In article <hl1ban$hes$1(a)news.eternal-september.org>, mscottschilling(a)hotmail.com says... > > Pitch wrote: > > In article <hkvi82$usn$1(a)news.eternal-september.org>, > > mscottschilling(a)hotmail.com says... > >> > >> Suppose the call to "super()" needn't be the first line of a > >> constructor. Discuss the effect and/or legality of the following > >> code: > >> > >> class MyClass extends YourClass > >> { > >> public MyClass(int i) > >> { > >> if ( i > 0) > >> { > >> super(i); > >> } > >> } > >> ... > > > > If you look at super() as just another method call it's perfectly ok. > > But it isn't "just another method call", which is the point of the example. > It's the call that guarantees that the superclass, starting from a > completely uninitialized state, has been fully initialized. It needs to be > called precisely once, and that needs to be done before any instance methods > are called or instance fields accessed. I though we are talking about changes in the language so it doesn't mater if it's not a method right now, or if it's allowed only once to be called. If we are talking of possible changes to Java it could be just another method and it could be called more than once, ok? In that case your example works perfectly ok. -- stirr your cofee properly
From: Patricia Shanahan on 12 Feb 2010 09:39 Pitch wrote: .... > I though we are talking about changes in the language so it doesn't > mater if it's not a method right now, or if it's allowed only once to be > called. If we are talking of possible changes to Java it could be just > another method and it could be called more than once, ok? .... That would be the most dangerous possible type of change to the language, one that changes the semantics of existing syntax. Currently, the writer of a non-final class can count on exactly one constructor call per object created, except for "this" calls in the class code. Multiple constructor calls for the same object, especially if parameters change between calls, may break invariants such as final variables being initialized exactly once, and never changing. Patricia
From: Pitch on 12 Feb 2010 09:59
In article <U5mdnVQN4rmk9ejWnZ2dnUVZ_qSdnZ2d(a)earthlink.com>, pats(a)acm.org says... > > Pitch wrote: > ... > > I though we are talking about changes in the language so it doesn't > > mater if it's not a method right now, or if it's allowed only once to be > > called. If we are talking of possible changes to Java it could be just > > another method and it could be called more than once, ok? > ... > > That would be the most dangerous possible type of change to the > language, one that changes the semantics of existing syntax. Of course. I don't think this can be changed, I just want people to agree this restricton should have not be introduced at all. -- stirr your cofee properly |