Comments on: Generic variable to the current type

By: Brian Pontarelli

Brian Pontarelli — Mon, 09 Mar 2009 20:28:32 +0000

Hehe. Looks like someone has proposed this for inclusion in Java 7. Not sure if it will make it or not:

http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000107.html

By: Brian Pontarelli

Brian Pontarelli — Mon, 09 Mar 2009 20:21:54 +0000

See, they are identical in my case. The 'this' keyword is a compiler indicator to use the type of the variable. If b is a BaseBuilder, the method's return type will be BaseBuilder. If b is a FooBuilder, it will be a FooBuilder. This is the exact same way the generic works.

BaseBuilder[FooBuilder] b;
b.add().build();

FooBuilder b;
b.add().build();

These are the same. The type of B can _only_ be a FooBuilder or a sub-class for both. If you further cast out the known type, the compiler should fail in both cases:

BaseBuilder[FooBuilder] b;
BaseBuilder b_raw = b
b.add().build(); // FAIL

FooBuilder b;
BaseBuilder b_raw = b;
b.add().build(); // FAIL

Using a keyword (I like 'this') does the same thing (from the compilers perspective) as adding the generic information. It just provides a simpler mechanism with less cruft.

By: Matt Hellige

Matt Hellige — Mon, 09 Mar 2009 19:03:43 +0000

It’s tempting to introduce a special keyword like “ME” or “this” to mean something like “the concrete type of the eventual subclass.” But I think you’ll run into problems if you actually try to implement a type-checker for this language. The problem comes when checking a method call like “b.add().foo()” when the known type of b is just BaseBuilder (i.e., not a concrete subclass). The problem is: what does add return? You know it must be a BaseBuilder, but the whole point of the “this” return type is that you really need to know, for example, that it’s a FooBuilder: knowing that it’s BaseBuilder isn’t enough if foo() is only defined on FooBuilder.

This is the problem that the “extra” generic solves. If instead of BaseBuilder, you know that b is a BaseBuilder[FooBuilder], and instead of “ME” or “this” add returns a T (== FooBuilder, in this case), then the typechecker has the information that it needs to typecheck a call like “b.add().foo()”. So in some sense the generic isn’t extra: it serves to make the eventual concrete subclass known to the typechecker.

By: Brian Pontarelli

Brian Pontarelli — Fri, 06 Mar 2009 20:48:55 +0000

Yeah, that will work also. Either is fine. The compiler doesn’t care that the generic variable isn’t filled out in the definition. At least Java doesn’t care since it erases everything anyways and allows raw instances for generically typed classes.

The idea isn’t that it can’t be done in any language, just that it sucks to have to hack the language like that. With co-variant return types, we should be capable of creating these types of methods without any generic information. Actually, you could simplify it like this:

class BaseBuilder {
  public this add() {
  }
}

class FooBuilder extends BaseBuilder {
}

That’s the cleanest way.

By: Matt Hellige

Matt Hellige — Fri, 06 Mar 2009 20:12:32 +0000

Stupid WordPress ate my pre tags and my less-than sign… Trying again, the first line should be:

class BaseBuilder[T <: BaseBuilder[T]] { this: T =>

Will that work?

By: Matt Hellige

Matt Hellige — Fri, 06 Mar 2009 20:11:31 +0000

Scala lets you improve this a bit with a self type annotation. I don’t find the type parameter that ugly (after all, you need to get the actual type in there somehow), but the unchecked casts are nasty. Here’s the pattern in Scala:

class BaseBuilder[T
def add(): T = {
//...
this
}
def divide(): T = {
//...
this
}
def multiply(): T = {
//...
this
}
}

class FooBuilder extends BaseBuilder[FooBuilder] {
}

The “this: T =>” in the first line is the key. It says to treat “this” as having a static type of T rather than BaseBuilder. If anybody tries to subclass BaseBuilder without satisfying that requirement, it’s a compile error. (You can get the same effect by just doing “class BaseBuilder[T] { this: T => … }”, which just leaves off the bounds on T, but the error messages are uglier.) Anyway it basically allows T to act just like your ME type, and the compiler enforces it.

Incidentally, I’d make a few other changes if I were doing it in Scala: I’d make BaseBuilder a trait and clean up the syntax of the methods a bit. But basically that’s the idea…