Live data from Hacker News

TypeScript please give us reflection/runtime types

github.com

71–80 of 287 posts

Re: TypeScript please give us reflection/runtime types

#71
We have types at home.

My litmus test regarding whether I can even consider using a library in production is: does it have more stars than fartscroll.js?

https://github.com/theonion/fartscroll.js/tree/master

Most of the entries there are below that number, which begs the question: is this really that much of a problem that it mandates the drastic changes required?

I actually don't know if it's even doable, considering TS's structural type system, where the answer to the question "what type is X?" is not straightforward.

Re: TypeScript please give us reflection/runtime types

#72
post #5

There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…

> dynamically typed language, and that's also nice what is nice about a dynamically typed language? like, seriously, can you list some reasons for a dynamically typed language to exist?

Types can get complicated. To an extent that code gets extremely overcomplicated by using a typed language. Typed languages encourage to use many layers of DTOs and models.

With dynamic languages you can just code, without being held back by a OOP type system, but it can get very complicated to understand what the typed of you parameters and return values actually are.

Typescript gives you the best of both worlds.

Re: TypeScript please give us reflection/runtime types

#73
post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

> > TypeScript Needs to Emit Runtime Type Information

> This is not possible at all because TypeScript is a compiler.

Sorry, can you clarify? Many compilers exist in other languages that support RTTI, so it's not clear to me what you mean by this.

Re: TypeScript please give us reflection/runtime types

#74
post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

> This is not possible at all because TypeScript is a compiler

Not sure if this supports your point. Lots of compilers emit runtime type information, e.g. Golang, Java.

Re: TypeScript please give us reflection/runtime types

#75
post #5

There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…

Not necessarily. Consider const fooType = generateTypeInfo! (); Where `generateTypeInfo!` is a macro that expands to a JS object encoding the “Foo” type (e.g. if `Foo` a record type, `fooType` will be a record with its encoded field types). It still compiles to readable JavaScript. What this macro does break is that TS = JavaScript with type annotations, and all you need to do to compile is remove those annotations (…

I'm not sure what `generateTypeInfo!();` is supposed to be, but as far as I'm aware there is no way to execute anything in a JS engine from a type generic.

Re: TypeScript please give us reflection/runtime types

#76
post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

Nit: they're not asking for runtime type safety; they're asking for the ability to reflect on types (at compile time, to generate values) so that they can use type information at runtime.

This helps ensure runtime type safety because (for example) it would be great to have a generic "validation" function that takes an arbitrary interface and an arbitrary object and validates that object. One way to implement this would be to use /compile time/ reflection to generate code (TS code hypothetical, because I write C++ nowadays):

  function validate(obj: Any): T | null {
    switch constexpr (T) {
    case String:
      return typeof obj == "string" ? obj : null;
    case Array
      if (!Array.isArray(obj)) {
        return null;
      }
      for (const u of obj) {
        if (validate(u) == null) {
          return null;
        }
      }
      return obj;
    // ... more base cases
    }

    for (const prop: (keyof T) of Reflect.Properties()) {
      if (validate(obj[prop]) == null) {
        return null;
      }
    }

    return obj;
  }

  interface Date {
    year: String;
    month: String;
    day: String;
  }
It would be great if this could generate /JavaScript/ code:

  function validate__String__(obj) {
    return typeof obj == "string" ? obj : null;
  }
 
  function validate__Array$Date$__(obj) {
    if (!Array.isArray(obj)) {
      return null;
    }
    for (const u of obj) {
      if (validate__Date__(u) == null) {
        return null;
      }
    }
    return obj;
  }

  function validate__Date__(obj) {
    for (const prop of ["year", "month", "day"])) {
      if (validate__String__(obj[prop]) == null) {
        return null;
      }
    }
    return obj;
  }
Unfortunately this is not possible (AFAIK) in TypeScript currently, and will not be possible with TypeScript's current philosophy.

(The above example is a hypothetical TypeScript compiler that might support "templated" generic functions; with just RTTI TypeScript could accomplish the same thing in a non-templated function by passing in `T` as a function parameter at runtime and doing runtime comparisons on `T`.)

Re: TypeScript please give us reflection/runtime types

#77
post #5

There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…

TypeScript is not JavaScript with type annotations. One of the modes, may be. TypeScript supports emitting old JS constructions which look nothing like original typescript code. So it's more like type annotations + babel. Adding one more thing to this set. Extremely useful thing. I think it's a good idea. I miss it. It's crazy that I can't JSON.parse string into typed structure safely. Every other language can do that.

Re: TypeScript please give us reflection/runtime types

#78
I'm kind of doubting the real value of this.

For validation, ORMs, APIs, etc., once you move beyond the simplest cases, you need more information than is present in Typescript type information. And that's before we get to the app-specific concerns.

So you're going to end up with schemas, boiler-plate, code-generators, and/or glue code anyway. Not to mention the libraries to help manage this stuff.

It's not that it's completely unhelpful, but I think it's a partial solution, and not the tricky part either.

Re: TypeScript please give us reflection/runtime types

#79

Earlier quoted context omitted.

I'm misunderstanding your reasoning here. TS is already a new (superset) language which compiles to JS. Runtime types solve the problem of maintaining two duplicate, separate type systems -- one for compilation, one for validating data. I'm not seeing how that's related to OOP. For instance, my preferred workaround lib for this problem, `io-ts`, leans hard on functional programming.

Emitting types would run counter to several of TypeScript's Design Goals [0]. In particular, it would violate: > 3. Impose no runtime overhead on emitted programs. > 9. Use a consistent, fully erasable, structural type system. It's also explicitly called out as a non-goal in that doc: > 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, en…

If some design goals are stupid they must be changed. It's not god word. It's human word. And this human was wrong.

Re: TypeScript please give us reflection/runtime types

#80
post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

> This is not possible at all because TypeScript is a compiler Not sure if this supports your point. Lots of compilers emit runtime type information, e.g. Golang, Java.

Those languages all have runtimes that can consume the type information. TypeScript does not.
Post reply on HN