Proposal: Create extensible type definitions with javascript characteristics

[snowyu]

Suggestion

🔍 Search Terms

• Runtime Library
• Dynamic Declare Type
• Extensible Type Definition

✅ Viability Checklist

My suggestion meets these guidelines:

• [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [X] This wouldn't change the runtime behavior of existing JavaScript code
• [X] This could be implemented without emitting different JS based on the types of the expressions
• [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [X] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I had been using turbo pascal since version TP6 to D7. In the past, because of its ingenuity and flexibility, I could implement the AOP framework in the static compilation: to add feature by injecting directive into machine instructions.

Time flies like electricity. Later, an interesting functional scripting language attracted me. Its characteristic is neither efficiency nor rigor, but a very concise grammatical concept. It has only two concepts: function and value. For functional type In terms of language, this is not special, and its special magic is the prototype chain of value object.

In China, philosopher Laozi once said: "Dao begets One(nothingness; or reason of being), One begets Two(yin and yang), Two begets Three(Heaven, Earth and Man), Three begets all things. "

These three concepts make the endless possibilities of dynamic ability in JavaScript until the emergence of ES6 Class.

ES6 Class is definitely not the way of javascript. Because it introduces the new concepts, instead of relying on function, value, and prototype chain. Constructors can no longer be called like functions. Classes have become a new concept. Classes are not constructors, but The constructor points to the class. Java or C++ developers may be very happy to see ES6 Class. The standard setters of ES6 Class made Javascript Class become Java/C++ Class. We can learn the advantages of Java/C++, but it should never become them. The Javascript Class should be like Java/C++ Class, not be them.

StrongType is what Javascript lacks, and it is also necessary, which is more convenient for performance optimization and error checking. Thanks to Typescript and @ahejlsberg for making it possible.

But the type system of typescript is still not the javascript charactermatic way, which has led to similar issues that have not been resolved since 2014(#1263). Some people hope to add static members to the interface(#33892 #33916 #32452), although this does not fundamentally solve the problem. For example, Dynamic inheritance and mixin at runtime.

The flow type checker is also plagued by similar problems. @mroch. facebook/flow/issues/803|facebook/flow/issues/2048|facebook/flow/issues/1704|facebook/flow/issues/5208

Create extensible type definitions with javascript characteristics

By extending the declare type keyword to make the declaration type dynamic and functional, it should be possible to solve the above problems. And Realize the dynamic expansion of typescript language. Let me illustrate:

Sorry I do not good at typescript transpiler. So all are pseudo code.

// Let the transpiler know that the `inherits` function is a type.
// this function will be executed by the transpiler
declare type inherits(target: Constructor, ...sources: Constructor[]) {
  if (!isFunction(target)) throw new SyntaxError('argument "target" should be a constructor')
  const result = this.getTypeOf(target)
  sources.forEach(source => {
    if (!isFunction(source)) throw new SyntaxError('argument "source" should be a constructor')
    source = this.getTypeOf(source)
    // the class extends of the transpiler
    this.extends(result, source)
  })
  return result
}

import inherits from 'inherits-ex'

Even we can extend or totally change the class declaration.

// overwrite the class declaration of the transpiler
declare type class extends TypeScriptClassType {
  // parse the typescript code
  parse() {}
  // emit the javascript code
  emit() {
    // such as, use the function instead of the ES6 class
  }
  constructor(...) {}
}

[MartinJohns]

Related: #41577

[owl-from-hogvarts]

Some use cases:

With such functions, i guess, we will get ability to constract types from parsed static structures such as template strings. Consider the example:

// we want know what template params we have for that string
const templateString: string = "/some/parametrised/path/:id"

meta function metaParseTemplateString(str: string) {
  // implementation code which will parse string and figure out what params it has
  // then it will construct type represeting these parameters
  // and return them like:
  return type {
    id: string
  }
}

// somewhere later
const paramsForTemplateString: metaParseTemplateString(templateString) = {
  id: "someIdA154ds"
}

// but
const test: metaParseTemplateString(templateString) = {
  // error
  foo: 'asd'
}