镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Suggestion: typedefs #308

Description

@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).

Activity

  1. RyanCavanaugh commented on Jul 30, 2014

    @RyanCavanaugh
    Member

    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;
  2. ComFreek commented on Jul 30, 2014

    @ComFreek
    Author

    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.

  3. saschanaz commented on Jul 31, 2014

    @saschanaz
    Contributor

    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.

  4. teppeis commented on Nov 2, 2014

    @teppeis

    closed by #957 ?

  5. danquirk commented on Nov 3, 2014

    @danquirk
    Member

    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.

  6. added
    FixedA PR has been merged for this issue
    and removed
    Needs More InfoThe issue still hasn't been fully clarified
    Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.
    on Nov 3, 2014
  7. vlomshakov commented on Nov 14, 2014

    @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.

  8. mhegazy commented on Nov 14, 2014

    @mhegazy
    Contributor

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

  9. locked and limited conversation to collaborators on Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FixedA PR has been merged for this issueSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions