Programatically Modifying Types #4490

Activity

1. weswigham commented on Aug 27, 2015

   

   Wesley Wigham (weswigham)

   on Aug 27, 2015

   Member

   More actions

   So... you can actually type your example fairly nicely in TS 1.6:

   interface MixinFactory<T> {
       create: () => T;
   }
   
   type AnyCtor<T> = (() => void) | (new() => T);
   
   function compose<A>(ctor: AnyCtor<A>, a: A): MixinFactory<A>;
   function compose<A, B>(ctor: AnyCtor<A&B>, a: A, b: B): MixinFactory<A&B>;
   function compose<A, B, C>(ctor: AnyCtor<A&B&C>, a: A, b:B, c:C): MixinFactory<A&B&C>;
   function compose<A, B, C, D>(ctor: AnyCtor<A&B&C&D>, a: A, b:B, c:C, d: D): MixinFactory<A&B&C&D>;
   function compose(ctor: new() => any, ...mixins: any[]): MixinFactory<any> {
       ctor.prototype = _.extend({}, ...mixins);
       return {
           create() {
               return new ctor();
           }
       };
   }

   The only caveat is the arbitrary number of overloads - there's no way to say that it could take an arbitrary number of type arguments and "merge them all" using current syntax.

   Similarly, there's no way to get the types of an array literal passed through the system. This literal:

   var myMixins = [{
       a: 2
   }, {
       b: 'twenty'
   }, {
       doTheThing() {
           console.log('The thing!');
       }
   }];

   Has the type ({a: number} | {b: string} | {doTheThing: () => void})[]. Strictly speaking, we could do better in this case if we remembered the arity of literals like this and associated each type with its slot in the tuple-like array. Considering we support tuple types in many places already, inferring this literal to be a tuple type may not be the worst idea. Giving it the type [{a: number}, {b: string}, {doTheThing: () => void}] seems way more accurate to me. If we could do that, then when I do

   var factory = compose(() => {}, ...myMixins);

   we know that the best overload is compose<A, B, C>, rather than the present result: the inability to find a matching overload. Unfortunately I've been informed that there's some other issues with array-vs-tuple type uncertainty which can make it difficult for us to do that (what if the array is edited? Then its type changes. How do we know it changes? Ich.).

   Regardless - you can still do this:

   var factory = compose(() => {
   
   }, {
       a: 2
   }, {
       b: 'twenty'
   }, {
       doTheThing() {
           console.log('The thing!');
       }
   });
   export var __instance = factory.create();
   export type MyClass = typeof __instance;
   export var create = factory.create;

   (I personally think that it's cute that you can extract the type in that way, though it would be better if typeof could resolve a bit more than namespaces on its own)

   And have full types flowing throughout your code.
2. Daniel Rosenwasser (DanielRosenwasser)

   added

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.This issue needs a plan that clarifies the finer details of how it could be implemented.

   on Aug 27, 2015
3. kitsonk commented on Aug 28, 2015

   

   Kitson Kelly (kitsonk)

   on Aug 28, 2015

   ContributorAuthor

   More actions

   Wesley Wigham (@weswigham) thanks! The overloading hadn't fully occurred to me. A couple of thoughts:

   The only caveat is the arbitrary number of overloads - there's no way to say that it could take an arbitrary number of type arguments and "merge them all" using current syntax.

   I think it has been discussed other places, but potentially a rest operator for generics is a part solution? Though how to operate it it programmatically would still need to be addressed unless it is implied a ...R generic is always a intersection. Something like this:

   function compose<...R>(ctor: AnyCtor<R>, /*...*/);

   Another thought, extracting the type via typeof is certainly useful. I think the challenge, I am seeing at the moment is while the extra "hoops" to jump through to extract the class information would be ok for some writing code, it become increasingly difficult for me to create a rational API I could reasonably get someone else to use (same to the challenges of the earlier of having to decide the arbitrary number of types).

   I mentioned Decorators above too, but I didn't give an example. Here is where I see things becoming difficult:

   interface AfterAdvice {
       (target: Object, result: any, args: any[]);
   }
   
   function after(advice: AfterAdvice) {
       return function(target: Object, propertyKey: string, descriptor: TypedPropertyDescriptor<any>): TypedPropertyDescriptor<any> {
           let origFn = target[propertyKey];
           return {
               value: function () {
                   let result = origFn.call(target, arguments);
                   return advice.call(target, result, arguments);
               }
           }
       }
   }
   
   class A{
       @after(function () {
           return true;
       })
       foo(): string {
           return 'true';
       }
   }

   If I want a decorator to modify the type, I can't. I think the logic is the same for class decorators as well. It would be great if a decorator had some sort of ability to not only install functionality but change the type as well.

   I guess what I am asking for is that now is to allow operators to work on type aliases... for example:

   let type MyClass = typeof instance;
   MyClass.foo = typeof (a: string, b: number) => void;
   /* now MyClass type/interface has a property of foo which is a function */
   let myFactory = compose<MyClass>(/*...*/);

   Then I can do all sort of "magic" including handling the merging of type, intersections, conflict resolution, decoration and manipulation without it having to be supported "natively" in TypeScript...
4. DanielRosenwasser commented on Aug 28, 2015

   

   Daniel Rosenwasser (DanielRosenwasser)

   on Aug 28, 2015

   Member

   More actions

   Though how to operate it it programmatically would still need to be addressed unless it is implied a ...R generic is always a intersection.

   Sounds like you'd want $Either as well - check out #2710.
5. kitsonk commented on Jun 13, 2017

   

   Kitson Kelly (kitsonk)

   on Jun 13, 2017

   ContributorAuthor

   More actions

   This really has been solved in lots of other ways. I don't have a legitimate use case anymore for this.
6. Kitson Kelly (kitsonk)

   closed this as completedon Jun 13, 2017
7. microsoft

   locked and limited conversation to collaborators on Jun 19, 2018