Proposal to remove inheritance of static properties

[rjamesnw]

Moving over from here: https://typescript.codeplex.com/workitem/2047

I think this may warrant more discussion. I believe there should be some way to FORCIBLY allow a derived static function with completely different parameter types to be implemented. What if I want to have {TypeA}.create(x:number) and later {TypeB}.create(s:string) (where TypeB extends TypeA)? Well, for derived types with special parameters, it fails because the signature must match. :/ Derived type constructors are not bound by the same rules! This is a bad system when trying to implement type factories (for example, object pools for game development), and also prevents end users from extending types in the same manner as constructors. Again, constructors of derived types are NOT limited in the same way.

I propose to allow the addition of "new" (like in C#) to allow forcing new function signatures, since anyone who does obviously knows what they're doing, and shouldn't have their "hands held" in such manner. I'm aware that ES6 supports static side inheritance, but I'm sure it still allows developers to create overriding signatures.

[RyanCavanaugh]

If you're not using the types as first-class objects (I have to assume not since otherwise you would want the restriction of the derived class static type being a subtype of the base class's static type), why not just name the methods differently (createA / createB)? Just trying to understand the use case.

[rjamesnw]

So "System.SomeNameSpace.MyGreatObject.createMyGreatObject()" is acceptable for an end user API? ;) I don't think so - it doesn't look good at all. My framework right now (focusing on game creation) has object pools, and you can currently create them by calling "System.SomeNameSpace.SomeObject()" (the type currently is "System.SomeNameSpace.SomeObject.$Type" using a module) - but I'd rather have "System.SomeNameSpace.SomeObject" to be the class type AND to be able to call it like a function. Why this way? Because derived types currently can't have unique static function signatures matching the constructors of the type they represent (unless I give unique names). The reason currently for asking is because it would be nice to be able to simply call "System.SomeNameSpace.MyGreatObject.create()" with the same parameters as the constructor (and constructors allow different parameter signatures in derived types). Inherited static functions do not. Besides, you can call functions with or without new in JavaScript, I shouldn't need a "good reason" to make sure TypeScript can allow it also. ;)

All that said, if I could simply do "class Something { ():Something; ... }" (add call signature) just like I can currently do "class Something { [index:string]:any; ... }" that would also work for my case (I wouldn't have to add the nested ".$Type").

[filipbuchta]

Actually for your use case it would be far more better to have factory constructors like in Dart.

[rjamesnw]

Hmm... It's like you're trying to tell me something. lol. So, I should move to dart and forget trying to make TS better? ;)

[rjamesnw]

For the record, Dart doesn't do anything special. It's JavaScript in the end, and a "factory constructor" is just a callable function without using "new".

[basarat]

factory constructors like in Dart.

@rjamesnw that is what a callable class is : #183

[rjamesnw]

Yes, I'm aware. ;)

[RyanCavanaugh]

So "System.SomeNameSpace.MyGreatObject.createMyGreatObject()" is acceptable for an end user API?

Honestly, yes? 😐 I get that you want control to name your objects a certain way, but as a type system, we actually do have to enforce some constraints. If you're thinking about end-user consumption, the substitutability of the static side of the type is also something that deserves consideration, after all.

The difference between TypeScript and the C# new keyword is that new in C# actually can create a runtime behavior such that callers going through a base class reference still get the base class behavior. If there were some way to do this in JavaScript, then it'd be reasonable to have this; in TypeScript we're not going to add keywords that appear to have meaningful semantics, but don't.

It sounds like callable classes might be a better solution, as others have mentioned.

[rjamesnw]

Well, it's a shame you can't force a new signature, but whatever. At least callable constructors would solve my case (I was the one originally requested it on Codeplex, and just moved it over).