Make variable declarations open ended

[clark-stevenson]

This used to be on codeplex and I cannot find a reference here.

https://typescript.codeplex.com/workitem/917

The problem is that I have project.d.ts and lets say that it has a Point class with simple {x,y} properties.

project-plugin-coolvector.d.ts might come along tomorrow, and that Plugin JS might add a z property to the existing Point class.

If project-plugin-coolvector.d.ts attempts to export a Point class with a z property. You get a duplicate error. I looked at the JQuery plugins example on DT but project.d.ts must contain classes, since Point has a constructor.

I see no way of being able to support the direction of the project in this instance.

[danquirk]

It's not clear there's a good way to do this for var that doesn't lead to a lot of unsafe code. It's possible there's a way to do this for classes. It would be helpful to understand why you need to have open ended classes and where open ended interfaces are insufficient.

[clark-stevenson]

Thanks for your response 👍

In this particular project, there is a Game class in JS https://github.com/photonstorm/phaser/blob/master/src/core/Game.js

With its accompanying definition
https://github.com/photonstorm/phaser/blob/master/build/phaser.d.ts#L1948

And then there is a totally external plugin
https://github.com/lewster32/phaser-plugin-isometric/blob/master/src/Isometric.js#L50

It adds "iso" to the existing Game Class. Because the first link Game.js is a Class, it seems logical that the definition is a class. I cannot see how to make it an interface.

[clark-stevenson]

I seen this again today in a different project.

There was a Core class, and an extension added a new method called to the Core prototype time. Since Time.js is a class, and Core.js is a class. The property time cannot be added to core when the definition for time.d.ts is added.

I frequently come up against this problem and cannot seem to resolve it. I run into the interface suggestion but if that is the case, should classes simply be avoided?

[lucamorelli]

well, especially for definition files may be a useful features, because I see several libraries that when included add members to existing type. I don't know if is good to add this in your own code

[saschanaz]

I think classes will be required to be open-ended when browsers support subclassing from Array. https://status.modern.ie/subclassinges6
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array-constructor

For open-ended variables, are there some reasons not to do this?

declare var x: SomeInterface;
extend x: ExtensionInterface;
//x now becomes SomeInterface + ExtensionInterface

/*
same as
interface X { ... }
interface X { ... }
*/

[joepb]

In JavaScript we can extend ECMA classes:
Date.foo = function() {...}
One would expect this to be somehow supported by the TypeScript superset.

[basarat]

Proposal

If the following is declared:

declare class Foo  {
    static bar: any;
    bas():any;
}

It can be extended using another declaration:

// Amend Foo
declare class Foo  {
    static anotherStatic: any;
    anotherMember():any;
}

Reason

@danquirk

It would be helpful to understand why you need to have open ended classes and where open ended interfaces are insufficient.

Really for a convinient way to model classes. Currently one needs to rewrite the original definition to make it extensible. This is not simple to explain to someone brand new to TypeScript.

declare var Foo : FooStatic;
interface FooStatic { // Static properties
    new (): Foo;
    bar: any;
}
interface Foo{ // Instance properties
    bas():any;
}

// Amend Foo 
interface FooStatic  {
   anotherStatic: any;
}
interface Foo{
    anotherMember():any;
}