Lambda the Ultimate

Decent static analysis tools (including IDEA and FindBugs) do flag calls to non-private/non-final/non-static methods in constructor/initializer context, as well as constructors where "this" escapes the constructor scope.
I can see the danger of the overwritable call, but it looks like something that can also be useful. Is there a safe way to do it?

I am not sure why I would want "this" to escape the constructor scope, for an event handler? What is the danger here?

Some people at Microsoft Research wrote a paper about supporting non-null references in a Java-like language. Interestingly, non-null references subtly forced them to also tackle the problem of incompletely-initialized objects.

Declaring and Checking Non-Null Types in an Object-Oriented Language

If you avoid these two constructs in Java, you can be guaranteed that any referenced object was created by a call to a constructor, and that call was fully completed before any other reference to the object.

That's not true. If your class isn't final (or have a final finalize()) a subclass can get access to a partially constructed object if an exception happens in the constructor by overriding the finalize().

It's the sixth security anti-pattern in this presentation.

Java semantics (if such thing exists) is highly complex and there are many pitfalls due to feature interaction. I don't know if there are other situations where a partially constructed object could be accessed and we may never know if we covered all our bases, unless its semantics are formally defined.

It's the sixth security anti-pattern in this presentation.

Thanks for this link. It is interesting to see that all the anti-patterns shown there are directly due to either mutable state or inheritence. And some are not immediately obvious, even to the seasoned programmer. Good ammunition for the next FP-vs-OO flame war. :-)

Are there any OO languages with good static analysis support for mutable/immutable? In the solution to the first anti-pattern in the slides they use a shallow copy; it would be nice to have the compiler guarantee the contents of the mutable container really are immutable. One could then even perhaps go on to have the compiler optimize things like clone() based on knowing the im/mutability of the items.

You could presumably use generics and/or make new types in Java such that the collection could only have been constructed so that it contains no mutable objects. So do you roll everything yourself, or does your language give standardized things to you? Nullness, immutability... perhaps things which are too important to leave out of the core language?

A language that supports OO* and has good static analisys for mutability? You don't need to search further than Haskell.

_{*For large values of OO and small values of support. YMMV. This offer is void if you aren't a Haskell über-hacker.}

The ST monad and Oleg's regioned variant of it're worth mentioning under static analysis for mutability, too.

Ok I see now, they are both the same: an unknown method gets a reference to a partially-initialised object 'this'.

Would we need a special marker to say "method called by the constructor, do not read the value of instance variables in here" for init-type methods? And maybe, the constructor should hard-wire unmarked method calls to use the non-overridden version of them. Making the methods temporarily 'final' until the constructor returns. Which could break some (possibly buggy) programs. And I am not sure if it is type-safe (sound?).

The object should also make sure that it registers itself (eg. to an event handler...) after all initialisations, but Java does not support "after" blocks. Alternatively there could be a contract that the registrant does not access the object immediately, and that users run in the same thread as the object constructor. That seems very difficult. Defining an "after" block that is executed after all the constructors finish is undoubtedly easier.

If class were objects (as in Smalltalk) you could use class methods to initialize the object, not instance ones. Also it would make factory patterns a non-issue. The object state could be defined as a simple record (using & for object composition):

class Foo extends Baz {
    final int x;
    int y;
    //class method
    Foo Foo.new(Bar bar) {
        int i = baz() //calling class method named baz
        Foo this = Baz.new(bar) 
        return this;
    }
    //class method
    int Foo.baz() {
        //no this available
        return this.x * this.y; // error
    }

    int baz() {
        return x * y
    }
}

No problematic partial objects, descriptive constructor names are possible, polymorphic constructors (i.e. just pass an instance of Foo's subclass and invoke dynamically), hook methods in class methods are ok, separate validation and initialization issues, may cache objects instead of creating new instances all the time, etc. the benefits are many without going too far from Java's syntax.

Is there any reason this isn't done? I have always been amazed by the need to create a special syntax for just this operation. I guess it might be just to be closer to C++ syntax, but well that seems like a very veak argument.

If you don't have a special name for all constructors, e.g. new or ctor, you end up having to pass the name as a parameter to other classes. Think of a collection class that needs to be able to create default objects, it needs to know the name of the c'tor to use. Eiffel has to do this for example.

Named constructors are very useful though imagine a vector object with Vector2d.cartesian(x, y) and Vector2d.angular(rho, length). Or Length.metres(m), Length.inches(i). There is a named constructor idiom for C++/Java/C# that emulates this though.

You still need syntax to create the 'naked' object. Based on the example above using C9x-esque structure litral sysntax:

Foo Foo.new(int x, int y) {
    Foo this = { .x = x, .y = y };

    return this;
}

In general I think the reason this elegant and clean solution isn't used is lack of imagination.

For a very nice system which includes this idea, see A Core Calculus of Metaclasses. I really enjoyed this paper and seem to recommend it every chance I get... I'd love to play with a language based on this.

Google for ESC-Java and JML. There's a lot of work out there.

...Krakatoa, Daikon, and DSD-Crasher.

Ob. FP note: one of DSD-Crasher's developers, Yannis Smaragdakis, is also co-developer of FC++, arguably the first really good implementation of functional programming techniques in C++ (but see Phoenix V2 for the current state of the art).