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: Lew on 9 Feb 2010 13:59
Lew wrote:
>> 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.

Eric Sosman wrote:
> Are you sure the method can be non-static?
> ... the compiler complains "cannot reference this before supertype
> constructor has been called" at the point of the method call.

(Mike Schilling pointed this out as well.)

I'm wrong.

--
Lew
From: Steven Simpson on 9 Feb 2010 15:44
On 09/02/10 16:36, Mike Schilling wrote:
> Steven Simpson wrote:
>
>> 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.
>>>
>> 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()".
>

I know - I snipped the example from the message I quoted. Didn't think
it was relevant, as I'm just curious as to any technical reason for the
restriction.

As it happens, it might have been relevant, as any expressions appearing
as arguments of super() effectively are prior to it, and the compiler
(as I recall) has to check them for reference to 'this' anyway.

--
ss at comp dot lancs dot ac dot uk

From: Lothar Kimmeringer on 9 Feb 2010 16:05
Patricia Shanahan wrote:

> Markus Eberle wrote:
>>
>> Catching an exception of the super constructor seems to be unwise, as
>> the object is then in an undefined state.
>
> That is why one should "possibly log, wrap and rethrow" the exception,
> not ignore it.

There are so many ways this might end up in a catastrophe
that it's easier to expect the logging to happen in the
class calling the constructor catching the exception.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: spamfang(a)kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
From: Lew on 9 Feb 2010 16:58
Mike Schilling wrote:
>> You can accomplish this in a roundabout way by calling a static method in
>> the arguments to "super()".

Steven Simpson wrote:
> I know - I snipped the example from the message I quoted. Didn't think
> it was relevant, as I'm just curious as to any technical reason for the
> restriction.

The technical reasons are laid out in the other thread on this topic,
appearing under subject 'object relational database versus "inteligent"
serialization'.

I think of it as the system requiring that there be an object before you can
act on it.

> As it happens, it might have been relevant, as any expressions appearing
> as arguments of super() effectively are prior to it, and the compiler
> (as I recall) has to check them for reference to 'this' anyway.

Thus the requirement that methods or other arguments in the constructor not be
instance-level.

--
Lew
From: Roedy Green on 9 Feb 2010 19:43
On Tue, 09 Feb 2010 16:22:35 +0000, Steven Simpson <ss(a)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.

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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: What is the difference between Memory Usage and Heap Usage in my JVM Metrics ?
Next: Java Lead with GUI & SWT | CA | 10+ months