cloneNode should return sub type, not Node

[dlee]

When I do someElement.cloneNode(), I want the returned element to be the same type as someElement, but right now it's returning type Node.

[DanielRosenwasser]

I assume that you have something like the following code

var d: Document;
var x = d.cloneNode(); // 'x' is of type 'Node'

but you wanted the resulting type of d.cloneNode() to be Document as well.

This is something that cannot "automatically" be expressed by our type system (nor can it be in type systems such as Java, C#, but has been "solved" in certain other languages).

One thing we could do is make cloneNode generic so that you could do:

elem.cloneNode<Document>();

and have that return a Document - but you're not gaining much over using a type assertion.

Something that allows you to get exactly what you want would be to define your own helper function so that you generally won't have to supply the generic parameter since it can be inferred.

function cloneNode<T extends Node>(node: T) {
    return <T>node.cloneNode();
}

var d: Document;
var x = cloneNode(d); // 'x' is of type 'Document'

[fsoikin]

@DanielRosenwasser, thus can be nicely solved with generic "this"argument, as in #285.

[DanielRosenwasser]

My comment was misleading. I meant to say that there is no way to automatically indicate to the compiler that a method should return the statically known subtype of a type.

In fact, we could include a signature on all subtypes of Node such that cloneNode() returns the appropriate type (we could also do certain things involving generics which would probably be a bit overkill).

[RyanCavanaugh]

Agree that this is basically the same issue as #285.

[Arnavion]

@DanielRosenwasser @RyanCavanaugh

Now that TS has this for return types, can this be done?

interface Node {
    cloneNode(deep?: boolean): this;
}

It'd technically be a lie though, since it returns a new object, not itself. Not sure if that matters.

Otherwise would it be okay to add an overload of cloneNode to every Node subtype in dom.generated.d.ts ?

[RyanCavanaugh]

I think : this should be correct here?

[DanielRosenwasser]

Wouldn't cloneNode be inherited from Node itself?

[Arnavion]

@RyanCavanaugh

The thing is : this is only really suitable for functions that really do return this, not a clone.

interface Cloneable {
    clone(): this;
}

class Foo implements Cloneable {
    clone(): this {
        // Error. Can work around by asserting to `any`,
        // but still semantically wrong if not overridden by every derived class.
        return new Foo();
    }
}

It doesn't matter as much for Node and the in-built HTML elements since they have opaque implementations of cloneNode and we can assume the browser implements them correctly. But maybe it'll matter somewhere else (custom elements?) and in general is not correct.