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: Steven Simpson on 9 Feb 2010 11:22 Eric Sosman wrote: > On 2/9/2010 4:49 AM, Pitch wrote: >> Also, you cannot place any code before super(...) which I already new, >> and it also sucks. :) > [...] >> Anyone knows why is that so? > [...] If it were possible to > run arbitrary code on a Sub instance before its Super-ness had > been established and its Super invariants put in place, you'd > be working with a Sub that was a Super in name only, but not in > actuality. Could that restriction not be loosened in a compiler-verifiable way, i.e. check that no statement prior to super() uses 'this' (explicitly or implicitly)? Therefore, there would be no arbitrary code acting on the Sub instance, until after super(). -- ss at comp dot lancs dot ac dot uk
From: Lew on 9 Feb 2010 11:35 Pitch wrote: >>> Also, you cannot place any code before super(...) which I already new, >>> and it also sucks. :) >> [...] >>> Anyone knows why is that so? Eric Sosman wrote: >> [...] If it were possible to >> run arbitrary code on a Sub instance before its Super-ness had >> been established and its Super invariants put in place, you'd >> be working with a Sub that was a Super in name only, but not in >> actuality. Steven Simpson wrote: > Could that restriction not be loosened in a compiler-verifiable way, > i.e. check that no statement prior to super() uses 'this' (explicitly or > implicitly)? Therefore, there would be no arbitrary code acting on the > Sub instance, until after super(). Anything is possible, but it isn't going to happen. In the thread you abandoned to post this, Steven, there was a code example of why it isn't necessary. -- Lew
From: Mike Schilling on 9 Feb 2010 11:36 Steven Simpson wrote: > Eric Sosman wrote: >> On 2/9/2010 4:49 AM, Pitch wrote: >>> Also, you cannot place any code before super(...) which I already >>> new, and it also sucks. :) >> [...] >>> Anyone knows why is that so? >> [...] If it were possible to >> run arbitrary code on a Sub instance before its Super-ness had >> been established and its Super invariants put in place, you'd >> be working with a Sub that was a Super in name only, but not in >> actuality. > > Could that restriction not be loosened in a compiler-verifiable way, > i.e. check that no statement prior to super() uses 'this' (explicitly > or implicitly)? Therefore, there would be no arbitrary code acting > on the Sub instance, until after super(). You can accomplish this in a roundabout way by calling a static method in the arguments to "super()"
From: Lew on 9 Feb 2010 11:39 Eric Sosman wrote: >>> [...] If it were possible to >>> run arbitrary code on a Sub instance before its Super-ness had >>> been established and its Super invariants put in place, you'd >>> be working with a Sub that was a Super in name only, but not in >>> actuality. Steven Simpson wrote: >> Could that restriction not be loosened in a compiler-verifiable way, >> i.e. check that no statement prior to super() uses 'this' (explicitly >> or implicitly)? Therefore, there would be no arbitrary code acting >> on the Sub instance, until after super(). Mike Schilling wrote: > You can accomplish this in a roundabout way by calling a static method in > the arguments to "super()" The method doesn't have to be static. The advantage of a static method is that the compiler will complain if you refer to instance members, thus preventing you from relying on incompletely-constructed elements. -- Lew
From: Volker Borchert on 9 Feb 2010 12:23
Mike Schilling wrote: > You can accomplish this in a roundabout way by calling a static method in > the arguments to "super()" Maybe so, but the most interesting thing to "do" before super() would be try{ ..., to catch, possibly log, wrap and rethrow exceptions thrown by the super ctor -- "I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy(a)ncc1701.starfleet.fed> "I'm a mechanic, not a doctor." Volker Borchert <v_borchert(a)despammed.com> |