From: Steven Simpson on
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
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
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
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
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>
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Ugly SAX
Next: Ploblem doing HTTP POST via URLConnection