Suggestion: Allow type and value parameters for modules

[zpdDG4gta8XKpMCd]

Consider a situation when each class and function in the module depends on the same type/value parameters:

// current
module foo {
   export class C<a> {
      value: a;
      constructor(private areEqual: (one: a, another:a) => boolean) { /*...*/ } 
   }
   export function f1<a>(areEqual: (one: a, another: a) => boolean, ones: a[], anothers: a[]) : boolean {
       // ...
   }
   export function f2<a>(areEqual: (one: a, another: a) => boolean, values: a[], sample: a): number[] {
       // ...
   }
}

It would be awesome if such parameters went to the module level and were resolved at importing

// suggested
module foo<a>(areEqual: (one: a, another: a) => boolean) {

   export class C {
      value: a;
   }

   export function f1(ones: a, anothers: a): boolean {
      //...
   }
   export function f2(values: a[], sample: a): number[] {
      //...
   }
}



import foo = require('foo')((one: Date, another:Date) => one.getTime() === another.getTime());

[RyanCavanaugh]

It's kind of confusing -- what is the type of the value expression foo.C ?

[zpdDG4gta8XKpMCd]

interface CStatic {
   new() : CIntsnace;
}
interface CInstance{
   value: Date;
}

[RyanCavanaugh]

Sorry, I meant in the case where you hadn't written an import yet. It would just be disallowed to reference foo<a> except through an import ?

[zpdDG4gta8XKpMCd]

so module foo<a>(areEqual: (one: a, another: a) => boolean) is essentially a generic function that returns a resolved module when called with all required type and value arguments

answering your questions, can you currently refer a generic function in TS? yes, but it doesn't make much sense in most cases (unless for calling it once resolved)

i hope the analogy with generic functions can be used in this case

[zpdDG4gta8XKpMCd]

basically i wish we had OCAML's first class modules in TypeScript:

• http://okmij.org/ftp/ML/first-class-modules/first-class-modules.pdf
• https://realworldocaml.org/v1/en/html/first-class-modules.html

[danquirk]

I think if we fully supported local types and class expressions you could probably get what you want by making foo a generic class containing a variety of other generic types.

[zpdDG4gta8XKpMCd]

@danquirk I am afraid I am not following how it could work.

class X<a> {
   class Y {
      value: a;
   }
}

var x = new X<Date>();
var y = new x.Y(); // <-- is this going to be allowed? so that y.value is of Date

[danquirk]

@Aleksey-Bykov I certainly imagine considering making something like that work. Obviously I don't want to promise anything at this point though :) It doesn't seem all that different from this kind of thing that we allow today:

function aConstructor<T>() {
   return function anotherConstructor() {
       var data: T;
       return { value: data }
   }
}

var a = aConstructor<Date>(); // we don't allow 'new' here since this isn't void returning
var b = a();
var r = b.value; // Date

Those are essentially the static sides of your 2 classes. Each function could return an interface type describing the instance side, but of course the problem today is you can't define an interface inside aConstructor that would allow you to correctly type the instance side members like value. It probably still doesn't do everything you want in terms of first class modules like OCaml but I can imagine it gets you most of what you want with lower complexity/cost (both from an implementation perspective and a concept perspective).

[mhegazy]

With ES6 modules in place, we have shied away from any changes to the module system. it is already complicated enough, and there is not an implementation yet.