Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: reflection for interface? #1549

Closed
vilicvane opened this issue Dec 23, 2014 · 19 comments
Closed

Suggestion: reflection for interface? #1549

vilicvane opened this issue Dec 23, 2014 · 19 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds

Comments

@vilicvane
Copy link
Contributor

Interface is a useful tool in TypeScript, but sometimes we'll need to write two pieces of almost identical code for intellisense and functionality respectively.

Is it acceptable to add a simple statement for generating part of interface information (properties)?

E.g.

class SomeClass { }

interface ISubFace {
    abc: string;
    def: number;
}

interface IFace {
    str: string;
    num: number;
    obj: SomeClass;
    sub: ISubFace;
}

var faceInfo = reflect IFace;

Would emit:

var SomeClass = (function () {
    function SomeClass() {
    }
    return SomeClass;
})();

var _ISubFaceReflection = {
    abc: 'string',
    def: 'number'
};
var _IFaceReflection = {
    str: 'string',
    num: 'number',
    obj: SomeClass,
    sub: _ISubFaceReflection
};

var faceInfo = _IFaceReflection;
@saschanaz
Copy link
Contributor

This will help my ObjectExtensions.ensure library a lot.

@vilicvane
Copy link
Contributor Author

@saschanaz oops. sorry I din't read the comment carefully.

@saschanaz
Copy link
Contributor

@vilic No, I didn't suggest anything but just said that I like your suggestion.

var face: IFace;
ObjectExtensions.ensure(face, reflect IFace);

This will be much better than:

var face: IFace;
ObjectExtensions.ensure(face, { str: "string", num: "number", obj: SomeClass, sub: { abc: "string", def: "number" } });

@vilicvane
Copy link
Contributor Author

@saschanaz yeah, later I found that I misunderstood what you said... T-T my head is full of coffee, and it's too heavy to think...

@saschanaz
Copy link
Contributor

@vilic Haha, me too. It's 1:44 AM here and I feel I have to sleep now. Well... Merry Christmas (or merry Christmas eve) 😄

@vilicvane
Copy link
Contributor Author

@saschanaz lol, Merry Christmas, and good night~ :D

@danquirk
Copy link
Member

danquirk commented Jan 6, 2015

Run time type information (ie reflection) is currently outside our design goals (https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals). If we were to do something like what you're requesting it would most likely surface in the form of attributes like #1557

@danquirk danquirk closed this as completed Jan 6, 2015
@danquirk danquirk added Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds Out of Scope This idea sits outside of the TypeScript language design constraints labels Jan 6, 2015
@vilicvane
Copy link
Contributor Author

Hmm, I thought it was easy because it seemed like we only need to do some sort of traversing... But I still look forward to it, annotations are annoying and it's not how JSers code. Any way we just need the certain reflection generated when reflect is there, and it should be somewhat compile-time...

@saschanaz
Copy link
Contributor

We don't need:

var obj: any;
var reflected = reflect obj;

but we do need:

interface A { /* ... */ }
var reflected = reflect A;

and this should be able to be done on compile-time.

@ipy
Copy link

ipy commented Feb 1, 2015

+1 for this feature. It will be of great help to deal with POJO ajax data and convert their types.

@meirgottlieb
Copy link

@vilicvane
Copy link
Contributor Author

@meirgottlieb that is great but I guess it won't fit the needs. :'(

@ghost
Copy link

ghost commented Mar 19, 2015

Will TypeScript have reverse-engineering features like Reflection in Java, PHP and C#? It would be great to when we say TypeScript will be used with server-side programming instead of Node.js etc. The annotation feature of TypeScript is great. Reflection would be greater!

@remojansen
Copy link
Contributor

👍 I also think that it would be great to be able to access interfaces via reflection. Though I don't need that level of detail. The name of the interfaces would be enough.

#3148

@electricmonk
Copy link

+1, would be very useful for stubbing interfaces, a-la Mockito (http://mockito.org/), something like:

interface Animal {
   makeSound(): void;
}

const anAnimal = Mock.<Animal>create();
...
anAnimal.makeSound();

@typeofweb
Copy link

Unfortunately tscompiler-reflect project is discontinued. Is there any way to get runtime type check in TypeScript? RTTC was one of the main design goals of AtScript.

@jianwu
Copy link

jianwu commented Mar 31, 2016

+1. I really hope to see typescript supports Java like reflection which is very useful for metadata driven designs such as use type information to generate auto-completion UI. The type information is valuable information which shouldn't be erased at runtime.

@blue112
Copy link

blue112 commented Jul 21, 2016

+1. This is a must have feature in any grown up language. One cannot be expected to rewrite all the types of an interface over again just to check the type.

@shumy
Copy link

shumy commented Feb 1, 2017

The "keyof" and "reflect" is not the same! This has type information and can probably be usefull e.g in Angular2 Dependency Injection, injecting Interfaces.
We can have both or at least "reflect" that is more generic with.

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds
Projects
None yet
Development

No branches or pull requests