Proposal: Create extensible type definitions with javascript characteristics

Suggestion

🔍 Search Terms

• Runtime Library
• Dynamic Declare Type
• Extensible Type Definition

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• 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(...) {}
}

Aucun fichier d’implémentation ni test n’est indiqué. Commencez par examiner les objectifs de conception de TypeScript et les issues associées référencées dans la proposition, notamment #1263, #33892, #33916 et #32452 ; le travail serait considéré comme terminé lorsqu’une spécification concrète et approuvée des définitions de types extensibles, plutôt que du pseudocode, serait disponible.