Suggestion: typedefs

[ComFreek]

Suggestion: Allow typedefs for aliasing types, class names and interface names

Use case:

// 1. Use case overlaps with interface functions types and is even uglier
typedef (number) => number MyCallback;

// 2. With generics
typedef Vector<SomeDataType> MyVector;

// 3. With primitive data types
typedef string MyData;

// 4. Aliasing classes and interfaces
typedef ReallyLongClassName ShortName;
typedef otherModule.subModule.subModule.Runnable Runnable;

Question: Do we need them?

1. Assigning a name to function types is already possible using interface function types. In my opinion, their syntax is nicer and we should not introduce another syntax for the same feature.
2. This can help minimzing the amount of typing.
3. According to the last comment of the original CodePlex issue, this can help commenting the code. It does however introduce another layer of name aliasing for names which are already short (number, string, boolean).
4. This can also help minimzing the amount of typing, especially for accessing external classes and interfaces inside deeply nested modules. Aliasing modules themselves would also be imaginable.

---

The original CodePlex issue: http://typescript.codeplex.com/workitem/119
Note that many of the given code examples are already covered by #14 (union types).

[RyanCavanaugh]

I'd like to see more compelling examples of things that you can't do with existing syntax; we don't want to have a bunch of ways to accomplish exactly the same thing.

The only cases that aren't already possible are re-naming the primitive types, which I think many people would argue is a bad thing to do in the first place, and shortening a class name where the class name doesn't come from a module (which is sort of a code smell to begin with -- a class name so long you can't even use it as-is?).

// typedef (number) => number MyCallback;
interface MyCallback {
    (n: number): number;
}

// typedef Vector<SomeDataType> MyVector;
interface Vector<T> { }
interface MyVector extends Vector<number> {}

// 3. With primitive data types
// typedef string MyData;
// (not possible)

// 4. Aliasing classes and interfaces

// typedef ReallyLongClassName ShortName;
class ReallyLongClassName { }
// (not possible; don't make your class names too long to start?)

// typedef otherModule.subModule.subModule.Runnable Runnable;
module otherModule.subModule.subModule { export class Runnable { } }
import Runnable = otherModule.subModule.subModule.Runnable;

[ComFreek]

I didn't know about the import statement.
I agree with you on all points except for aliasing the generic interface (or class) since it's semantically not the same as a typedef. But I wouldn't add typedefs for this sole reason either.

[saschanaz]

By the way, I like mwisnicki's syntax suggestion:

type Server = http.Server | myApp.Server;
type Z = x.y.Z;

This would be able to cover (potentially) union types, import statement, and typedef here.

[teppeis]

closed by #957 ?

[danquirk]

Yeah, type aliases are essentially this with a well defined set of rules. If people have issues with the current implementation do comment over in the type aliases issues or log bugs as appropriate.

[vlomshakov]

It seems to me, it's very strange, that import declaration can't make alias for not qualified symbol (see example above - Aliasing classes).
Now I have to use next way to do this:

class S {}

export type SS = S;
export var SS = S;

Maybe, this suggested typedef is more useful than combination of type alias and var alias.

[mhegazy]

@vlomshakov can you log a separate issue for removing the qualified name restriction on import targets.