Why does this() and super() have to be the first statement in a constructor?

[Henri Gerrits]

Ulf,

In rule 1, using a field access as the left-hand operand in a simple (not compound, of course) assignment could be allowed before an explicit call to this() or super().
In rule 2, by "1." I assume you mean "first"?

Regards,

Henri

----- Original Message -----
> From: Ulf Zibis <Ulf.Zibis at gmx.de>
> To: joe.darcy at oracle.com
> Cc: coin-dev at openjdk.java.net; Mike Duigou <mike.duigou at oracle.com>
> Sent: Thursday, October 13, 2011 7:53 AM
> Subject: Re: Why does this() and super() have to be the first statement in a constructor?
> 
> Joe,
> 
> now I'm a little bit confused.
> 
> First you refer simply:
> "The answer to the question has already been given on the list. ..."
> Now you point to Bug 4093999 with IMHO very sophisticated loosening cases, e.g.: 
> obj.super().
> 
> I think, as first step, this request could be handled like as on switch 
> enhancements (only for 
> String, but not for all objects or arbitrary expressions).
> 
> Following loosening rules seem simple, clear and enough to me:
> 1. Allow the explicit call to super() or this() only before any reference to 
> this or instance fields 
> or methods.
> 2. In case where no explicit call to super/this() is given, add implicit call to 
> the no params 
> super() as 1. statement.
> 3. Allow super() or this() call only outside any block ({...}, if, for, etc.), 
> maybe except 
> synchronize block.
> 4. Allow only one of super() or this() and only once.
> 
> Further loosenings could be discussed later, as they need complicated data flow 
> analysis.
> 
> I agree, that other language changes might have higher priority.
> 
> -Ulf
> 
> 
> Am 12.10.2011 03:24, schrieb joe.darcy at oracle.com:
>> 
>> As pointed out in the thread cited by Mike, there were technical issues 
> discussed in various 
>> related bugs, in particular
>> 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4093999
> 
>> 
>> IMO this loosening would be fine in and of itself, but it has too high an 
> opportunity cost 
>> compared to other language changes that could be done with the same amount 
> of effort.
>> 
>> -Joe
>