Skip to content

Proposal for complete reflection mechanism #11362

Closed

Description

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

Activity

  1. changed the title [-]Proposal for complete reflection mecanism[/-] [+]Proposal for complete reflection mechanism[/+] on Oct 4, 2016
  2. pcan commented on Oct 29, 2016

    @pcan
    Contributor

    JDavid Luque (@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.

  3. mhegazy commented on Apr 27, 2017

    @mhegazy
    Contributor

    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.

  4. locked and limited conversation to collaborators on Jun 19, 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

    Domain: DecoratorsThe issue relates to the decorator syntaxOut of ScopeThis idea sits outside of the TypeScript language design constraints

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions