Loosen Constructor super()/this() call restrictions (original) (raw)

Mark Mahieu markmahieu at googlemail.com
Sun Mar 22 18:50:36 PDT 2009

Marek,

Other than being able to give a name to your 'initializers', I'm not sure what you're gaining with that compared to what's already supported, eg: class Foo {

private final int i;

public Foo() {
    this(42);
}

private Foo(int j) {
    i = j;
}

}

Regards,

Mark

2009/3/23 Marek Kozieł <develop4lasu at gmail.com>

2009/3/23 Mark Mahieu <markmahieu at googlemail.com>: > 2009/3/23 Jeremy Manson <jeremy.manson at gmail.com> >> >> For example, now that this() and super() can come in the middle of a >> constructor, are the semantics implicitly changed so that you can >> catch exceptions thrown by this() and super()? Does that mean that >> objects can now be seen as partially initialized in sub-constructors? >> > > Ha, there's a bug entry for that one too: > http://bugs.sun.com/bugdatabase/viewbug.do?bugid=4879515 > > Mark > >

this() super() work 100% correctly now days. But maybe the thing you need is not this 'weird' behavior of constructor. Consider new kind of method 'initializer': - Can be executed only in constructors. - Can assign value to final fields, only condition is to assign it always.

class Sample{ final Foo foo; final Bar bar; public Sample(FooBuilder foo, Bar bar){ initFoo(foo); // compiler known that foo is assigned this.bar = bar.copy(); } public Sample(FooBuilder foo, BarBuilder bar){ initFoo(foo); // compiler known that foo is assigned initBar(bar); // compiler know that bar is assigned } public Sample(Foo foo, BarBuilder bar){ this.foo = foo.copy(); initBar(bar); // compiler know that bar is assigned } initializer void initFoo(FooBuilder foo){ //operations to create foo // we have foo this.foo = foo; } initializer void initBar(BarBuilder bar){ //operations to create bar // we have bar this. bar = bar; } } -- Pozdrowionka. / Regards. Lasu aka Marek Kozieł http://lasu2string.blogspot.com/

More information about the coin-dev mailing list