Outline view presents constructor for class Foo as Foo() instead of this().

Polyglot only gives me the ClassName() ("Foo()") label back, even if it's defined as this().
Asking Nate.

Nate said: I overrode toString in X10ConstructorDecl. Lemme know if that works.

Looking at the image, it doesn't look like you're getting the string from toString anyway. If you can tell me where you're getting it, I can change it.

I'm getting it from name() and then adding in the formal parameters myself to get the args (see existing code below)

Hmmm. if i cast it to X10ConstructorDecl, the toString() says "public this(...)"
but the X10ConstructorDecl.name() still gives the classname

Existing code here (from X10LabelProvider)

} else if (node instanceof ProcedureDecl) {
    	    ProcedureDecl pd= (ProcedureDecl) node;
    	    List<Formal> formals= pd.formals();
    	    StringBuffer buff= new StringBuffer();
    	    buff.append(pd.name().id().toString());//PORT1.7 note that ProcedureDecl.name() re-added 10/1/08 by Nate
    	    buff.append("(");
    	    for (Iterator<Formal> iter = formals.iterator(); iter.hasNext();) {
				Formal formal =  iter.next();
				buff.append(formal.type().toString());
				if (iter.hasNext())
					buff.append(", ");
			}
    	    buff.append(")");
    	    return filter(buff.toString());

It's the issue of where the name comes from. Normally, for constructors created in the parser, name is set to nf.Id(pos(3), "this"). However, there are more places where constructors are created – namely, ClassDecl_c.createDefaultConstructor() and LocalClassRemover.addConstructor(). Both of these happen in Polyglot, and are never overridden. Both use the class name as the constructor name.

I've fixed the first one in SVN. However, I can't fix the second without duplicating large chunks of code from Polyglot. The right solution is to create a method constructorName() in LocalClassRemover, and make that overridable. That way, X10LocalClassRemover can control what the constructor's name is.

A better solution would be to remove the name node from constructors altogether, or, at least, make it part of the protected functionality (i.e., let subclasses override it, but do not expose the name to outside clients).

The name is stored in the node because of Java. The following should be an error:

class A {
    B() { }
}

The parser will not examine the name to make sure it matches the declared class name. Instead, the name in the constructor node is compared against the class name during type checking. So, we can't remove the name from the node that easily.

But, yes the name can be made protected.

Moving all open items for X10DT 1.7 to X10DT 2.0 since 1.7 has been released.

moving open issues in X10 DT 2.0.1.1 to X10 DT 2.0.2.2 as discussed with Bob.

This was the result of the front-end's replacing "this" with the containing class name. Instituted a work-around in the X10LabelProvider.

bulk close of all resolved issues as part of closing 2.0.4 items.