«

On Tue, 09 Feb 2010 16:22:35 +0000, Steven Simpson <>
wrote, quoted or indirectly quoted someone who said :

>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)?

It would have to chase any method calls recursively. They might
dynamically load code. I don't think you can tell in general.

Perhaps you could allow an expression involving only literals, static
finals and parameters.

The restriction is onerous. Often I want to transform the constructor
parameters to pass to the super constructor.

Oddly you are allowed method calls in the superconstructor, which
could do bloody well anything.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Every compilable program in a sense works. The problem is with your unrealistic expections on what it will do.

On Feb 10, 1:43*am, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> On Tue, 09 Feb 2010 16:22:35 +0000, Steven Simpson <s...@domain.invalid>
> wrote, quoted or indirectly quoted someone who said :
>
> >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)?
>
> It would have to chase any *method calls recursively. They might
> dynamically load code. *I don't think you can tell in general.

I think you can. You don't have to chase anything: if you encounter
this.foo() or super.foo() or bar(this), the code is illegal, else it's
not. There's no other way for method calls to access the 'this'
reference. Of course besides method calls you have to guard against
other expressions involving this, like baz = this, quux == this and so
on, but those are easy.

> Perhaps you could allow an expression involving only literals, static
> finals and parameters.

That would be sensible.

> The restriction is onerous. *Often I want to transform the constructor
> parameters to pass to the super constructor.

I often do, too. Also try-catch-rethrow is quite a common need.

> Oddly you are allowed method calls in the superconstructor, which
> could do bloody well anything.

You're right, I never thought about that! Methods can be overridden in
the subclass and access fields that have not yet been initialized, if
they are called from the super constructor. One more sign that
disallowing statements before super() does not guarantee any
additional safety.

Alessio

In article <b366f0eb-11ae-48bb-86b1-67eff9b81a88
@k41g2000yqm.googlegroups.com>, says...

> > Oddly you are allowed method calls in the superconstructor, which
> > could do bloody well anything.
>
> You're right, I never thought about that! Methods can be overridden in
> the subclass and access fields that have not yet been initialized, if
> they are called from the super constructor. One more sign that
> disallowing statements before super() does not guarantee any
> additional safety.


yep.



--
stirr your cofee properly