United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6479372 : Add self types (type of 'this' aka ThisClass) to the language

Details
Type:
Enhancement
Submit Date:
2006-10-06
Status:
Closed
Updated Date:
2011-10-31
Project Name:
JDK
Resolved Date:
2011-10-31
Component:
specification
OS:
linux,windows_xp
Sub-Component:
language
CPU:
x86
Priority:
P5
Resolution:
Won't Fix
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
A DESCRIPTION OF THE REQUEST :
The SelfType pattern (which goes by many names, and is closely related to the problem described in closed bug 6431633), in concept, is extremely useful for more sophisticated applications of generics.

The SelfType pattern in reality is a limited workaround for situations requiring the use the type of THIS class in the class definition. It takes the familiar form...

abstract class AbstractClass<THIS extends AbstractClass<THIS>> {
    abstract public THIS getThis();
    public void setPeer(THIS peer) {_peer = peer;}
    private THIS _peer;
}

class ConcreteClass extends AbstractClass<ConcreteClass> {
    public ConcreteClass getThis() {return this;}
}

Unfortunately, concrete classes, such as ConcreteClass cannot be extended with "this-awareness". Thus...

class ConcreteSubClass extends ConcreteClass {}

   ConcreteClass obj = new ConcreteClass();
   ConcreteSubClass subobj = new ConcreteSubClass();

    subobj.setPeer(obj); // !!!should be an error, but thisness is lost

The problem becomes even worse if you want two this-aware generic classes that mutually reference one another...

public abstract class AbstractPeer<THIS extends AbstractPeer<THIS,THAT>,
THAT extends AbstractPeer<THAT,THIS>> {
	public void setPeer(THAT peer) {
		_peer = peer; // this references that
		_peer.setPeer(getThis()); // that references this
	}
	
	public THAT getPeer() {
		return _peer;
	}
	
	public abstract THIS getThis();
	
	private THAT _peer;
}

public class AlphaPeer<THAT extends BetaPeer<AlphaPeer<THAT>>>
extends AbstractPeer<AlphaPeer<THAT>,THAT> { // !!!does not compile
	public AlphaPeer<THAT> getThis() {
		return this;
	}
}

public class BetaPeer<THAT extends AlphaPeer<BetaPeer<THAT>>>
extends AbstractPeer<BetaPeer<THAT>,THAT> { // !!!does not compile
	public BetaPeer<THAT> getThis() {
		return this;
	}
}



JUSTIFICATION :
Imagine if  the java language spec were to say that a concrete class could only be extended once.  Without some inherent support for a THIS type, that is essentially what is happening (and a lot more) in more sophisticated attempts at employing generics for code reusability.



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A robust this-awareness in generic classes, where concrete classes can be correctly extended, and where mutual references can be properly defined
ACTUAL -
A wimpy this-awareness in generic classes, which relies on generic constructs approaching the level of hieroglyphics (Foo<THIS extends Foo<THIS>)

                                    

Comments
EVALUATION

Proposals for new features in the Java programming language are no longer being accepted or maintained in the bug database at http://bugs.sun.com/. This also applies to proposals for new features in the Java Virtual Machine (that is, in the abstract JVM, as opposed to a JVM implementation like HotSpot).

All proposals for new features should be made through the "JDK Enhancement - Proposal & Roadmap Process" described at http://openjdk.java.net/jeps/1.

Consequently, this specific request to change the Java programming language will not be considered further.

The bug database continues to accept and maintain submissions about technical errors in the design and specification of the Java programming language and the Java Virtual Machine.
                                     
2011-10-31
EVALUATION

Kim Bruce and Nate Foster have studied this extensively:
http://www.cis.upenn.edu/~jnfoster/papers/looj.pdf

ThisClass/ThisType is useful for any binary method, not just "more sophisticated applications of generics" as in the Description.
                                     
2006-11-09
EVALUATION

Other languages, notably Strongtalk (http://www.strongtalk.org/), have
used self types.  To type check any Smalltalk variant, the this type is
essential.  However, it does not come without restrictions, for example,
it can only be used in covariant places (return types as in the above
example, not method parameter types).

If self types were added to the language, it would be natural to consider
the return type of clone.  However, changing the return type of clone to
use a self type would not be compatible with existing applications and
likely to cause a lot of problems.

In general, the impact on the rest of the language from adding self type
is likely to be just as big as adding generic types.  Contrary to Strongtalk,
the use in Java would be limited and covariant return types can be used
to solve most of the problems that can be solved with self types.

So it is not likely that we will see self types in the Java programming
language.
                                     
2006-10-09
EVALUATION

I think the submitter is looking for something like this:

class Foo {
    protected this clone() {
        return (this) super.clone();
    }
}
                                     
2006-10-06



Hardware and Software, Engineered to Work Together