Statements before super()
in [Java Help]
|
Prev: What is the difference between Memory Usage and Heap Usage in my JVM Metrics ?
Next: Java Lead with GUI & SWT | CA | 10+ months
From: Patricia Shanahan on 12 Feb 2010 10:12 Pitch wrote: > 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. > > Which restriction are you arguing against? I think the rule that ensures that a subclass invokes a constructor for its superclass exactly once, before any use of "this", is a good invariant that simplifies the code in non-final classes. On the other hand, I believe that invariant, and a related invariant ensuring a superclass constructor call before completion other than by throw, could be enforced while allowing a lot more flexibility in subclass constructors. Patricia
From: Pitch on 12 Feb 2010 11:09 In article <87-dnf82RLR-8ujWnZ2dnUVZ_j6dnZ2d(a)earthlink.com>, pats(a)acm.org says... > > Pitch wrote: > > 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. > > > > > > Which restriction are you arguing against? I think the rule that ensures > that a subclass invokes a constructor for its superclass exactly once, > before any use of "this", is a good invariant that simplifies the code > in non-final classes. But it complicates the code if you want to change the behaviour of the initialization process. Why not leave it up to programmers. We can use a bolean flag if we need a once-only initialization. > On the other hand, I believe that invariant, and a related invariant > ensuring a superclass constructor call before completion other than by > throw, could be enforced while allowing a lot more flexibility in > subclass constructors. And why is it so important to call superclass constructor and have a fully initialized members of the super class? Every progammer knows that there is a set of rules for every language and this isn't even a new rule! It's a good old: "Do not hide virtual methods!" Compilers have produced similar warnings for ages now. (In this case constructor will be virtual, of course.) And what if I don't let the superclass members be initialized? I will produce an exception probably. Big deal. Please, look at this example class A { private String data = getData(); protected void getData() { return "A"; } } class B extends A { private String newData = "unknown"; public B(String data) { newData = data; } protected String getData() { return newData; } } When you instantate an object of type B, field A.data will be "unknown" instead of intended value "A". So the author of class A has allowed the subclass to change the behaviour of the superclass initailization. Woudn't it be simpler to put it like this: class B extends A { private String newData = "unknown"; public B(String data) { newData = data; super(); } protected String getData() { return newData; } } -- stirr your cofee properly
From: Joshua Cranmer on 12 Feb 2010 12:11 On 02/12/2010 09:59 AM, Pitch wrote: > 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. Even C++ requires that superconstructors be called before the constructor executes (although it does permit you to wrap the whole initializer in a try-catch block, which was incidentally the feature that originally prompted this IIRC). I can't think of a language which treats constructors as regular methods. C++ lists it as a "special member function", it's one of two special functions in Java (the other being, essentially, <clinit>). I think python also treats it specially as well. It is a very sensible restriction, and the expectation by programmers coming from other languages is that it will be. Constructors have the notion of actually reserving the memory space and then initializing it at the same time--hence we have the `new' keyword and the actual constructor call. If you were to separate the memory space reservation and initialization out, then it would make sense to allow constructors to be called multiple times. But Java doesn't allow you to do so, so the point is moot. In any case, I don't agree with the assertion "this restriction should not have been introduced." -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Mike Schilling on 12 Feb 2010 13:35 Pitch wrote: > 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. As I explained above, it breaks all guarantees about class construction. That's a bad thing.
From: Patricia Shanahan on 12 Feb 2010 14:09
Pitch wrote: > In article <87-dnf82RLR-8ujWnZ2dnUVZ_j6dnZ2d(a)earthlink.com>, > pats(a)acm.org says... >> Pitch wrote: >>> 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. >>> >>> >> Which restriction are you arguing against? I think the rule that ensures >> that a subclass invokes a constructor for its superclass exactly once, >> before any use of "this", is a good invariant that simplifies the code >> in non-final classes. > > But it complicates the code if you want to change the behaviour of the > initialization process. > > Why not leave it up to programmers. We can use a bolean flag if we need > a once-only initialization. One of the key decisions in language design is how much rope to leave lying around. A lot of rope makes it easy for programmers to accidentally hang themselves. Less rope makes accidental hanging less likely, but makes it harder to do things that need a lot of rope. Each language has its own trade-off between flexibility and built-in invariants. Java provides quite a lot of invariants. I use Java when that is what I want. I have had situations in which I needed a lot of flexibility and to be in control. For that, I use C and, if necessary, assembly language. Patricia |