Proposal for complete reflection mechanism

[jdavidls]

Proposal for complete reflection mechanism

Actual behavior:

class MyClass {
    @member
    arrayProperty: string[];

    @member
    mappingProperty: {
        [key:string]: MyClass
    };

}

function member(prototype, memberName: string){
    let designType = Reflect.getMetadata('design:type', prototype, memberName);

    // How to know the element type of an array property?
    // How to know the key type of an mapping property?
    // How to know the value type of an mapping property?
    // if there is no way of knowing this, Reflec is very partial reflection mechanism.
}

Expected behavior:

// complier options: ---emitDesign

class MyClass {
    arrayProperty: string[];
    mappingProperty: {
        [key:string]: MyClass
    };
}

function designUserFunction(type: Function, memberName: string){
    let classDesign = Design.get(type);

   let memberInfo = classDesign.members[memberName];

   if( memberInfo.kind == 'mapping' || memberInfo.isMapping ) {
       let mappingDesign: Design = memberInfo.value;
       let mappingKeyDesign: Design = memberInfo.value.key;
       let mappingKeyType = memberInfo.value.key.type; // String
       let mappingElementDesign: Design = memberInfo.value.element;
       let mappingElementType = memberInfo.value.element.type; // MyClass
   }
   else  if( memberInfo.kind == 'array' || memberInfo.isArray ) {
       let arrayDesign: Design = memberInfo.value;
       let arrayKeyDesign: Design = memberInfo.value.key;
       let arrayKeyType = memberInfo.value.key.type; // Number
       let arrayElementDesign: Design = memberInfo.value.element;
       let arrayElementType = memberInfo.value.element.type; // String
   }
   // ...
   // All type constructions of the language must be supported by Design,
   // this includes function design and tuples.
}

I have working this weekend in a workaround for this incomplete reflect behaviour, you can see the solution that I designed here.

To come up with this solution, I had to design a pseudo-expressions for language types. These pseudo-expressoins would not be necessary, along with the boilerplate decorators if all this are performed by the compiler when it is emmiting all reflective information.

I thing, It is just an opinion, this mechanism must be part of a TypeScript standard library, and nor part of ES standard, because they must be supported all type constructions that can be made in the language.

How many typed is TypeScript if its reflection mechanism is partial and dependent on an untyped language standard (ES)?

I hope apologize my google translated English, and at least discuss my proposal.

Thanks

---

I have not mentioned anything about the inheritance chain, but it is another of the characteristics that I believe fundamental in a complete system. Having to access the base class 'design' of a given class, and vice versa, to access the designs of derived classes from a base class. I will wrote an example in the source code i linked.

[pcan]

@jdavidls if you haven't seen it yet, please give a look at the customized version of the compiler that I released some months ago, you may be interested in it. It includes full reflection/type serialization capabilities. Link here. I hope that in a near future this can be added as a custom transformer with some kind of plugin API, but now it's not possible yet, so I forked the entire compiler.

[mhegazy]

As noted in #14971 (comment), reflection and runtime type serialization is outside the scope of the TypeScript project in the time being.

Relevant discussion in #3628.