Live data from Hacker News

TypeScript please give us reflection/runtime types

github.com

61–70 of 287 posts

Re: TypeScript please give us reflection/runtime types

#61
post #18

I’m mainly a backend programmer, so I know just a little typescript, but I don’t really understand what they’re asking for here. It sounds like they want to serialize and deserialize typescript types automatically? If so, that sounds like a good fit for a library, not something most languages offer. (Please educate me if I’m missing the point)

Javascript already has standard serialization and deserialization tools.

The problem is that the deserialization is untyped. It's just a Javascript object. Usually, the first thing you'll do is to cast it to a typed Typescript definition, but there's no way to guarantee that it actually fits that definition. No type information exists at runtime. It's used solely to check the code itself during compilation.

So any time you get data from outside of your program (over the network, from a database, out of a config file, etc.) you just have to hope that it actually fits the type. You can write code to check it... but you have to write that code yourself.

There are libraries you can use. For example, you can use a Data Description Language with a simpler type system, which usually suffices for the kind of data you want to serialize. Then you can use that to generate both a Typescript definition and a runtime type checker. But that's inelegant, and not standard, so every project is different despite it being something everybody needs.

Re: TypeScript please give us reflection/runtime types

#63

Typescript already kind of has it, it's just they got it backwards. One needs to define their types as a const, like this one: ``` [{ type: Number, name: "field1" }, { type: String, name: "field2" }] as const ``` and then use Typescript magic to convert it into the fully fledged Typescript type. Yes, it's annoying, but it's more flexible.

This is as useful as vue 2's prop types: very little.

Re: TypeScript please give us reflection/runtime types

#64
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?

Re: TypeScript please give us reflection/runtime types

#65

I vaguely remember one of typescripts developers stating that if they had to start it all over again, enums would not be added; as enums are the only thing emitting runtime code. Typescript does not change runtime behaviour, there is no special typescript {#if}

> I vaguely remember one of typescripts developers stating that if they had to start it all over again, enums would not be added; as enums are the only thing emitting runtime code.

It's true. I don't remember if that was the only/main reason they said that, but that was definitely one of the things.

I find that a weird sentiment, though, because TypeScript has a couple of other features that are not just "JavaScript + type annotations".

Namespaces is one. It also has a syntactic sugar for defining class properties in the constructor arguments. And it had that experimental decorator feature for a long time, but I never used it, so I don't know much about it. It also has the "`this` parameter" syntax for methods/functions, which does disappear at compile time, but still looks and feels like more than just a JavaScript function with type annotations.

Re: TypeScript please give us reflection/runtime types

#67
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…

At the top of the README they link to "The 7 year old Github issue" which describes the problem in they way you're asking for.

https://github.com/microsoft/TypeScript/issues/3628

Re: TypeScript please give us reflection/runtime types

#68

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…

Emitting type information to some kind of separate common format wouldn't undermine most of these goals. There are already apparently dozens of tools that people can use for this task in a dozen different ways. Just have TS emit the data.

In this way there is no runtime overhead (point #3) -- it's pure data to be optionally consumed. They wouldn't have to prescribe any particular reflection module (point #6).

The only point this would violate is #5 but that is, of course, the point. We want them to reconsider because it's such a powerfully useful feature. And people are doing it on top of and outside of TypeScript where TypeScript would be best tool to give this information for TS users.

Re: TypeScript please give us reflection/runtime types

#69

Thanks for this. I thought I was screaming into a void. I started with typescript in 2018 and after two years started to believe this is just not really a solution because what it is. I came from Haskell/c#/f#, and TS, while it has a very powerful type system, just doesn’t give you much of the advantages the above languages give you outside (some of) dev. Even when it does, it is really limited in practice (aka when…

The point of TypeScript was always to run on web, it wasn't meant to give you a language advantage over say, C#. You use C# if you have to develop for .NET, you use TypeScript if you have to develop for Web, you wouldn't use one or the other in another context.

That being said, TypeScript is differently capable from C#. C# is nominally typed, with decent reified generics. I like programming in C#, and miss its features when programming in TypeScript. TypeScript, on the other hand, is structurally typed, forgoes soundness, and comes with a powerful type system to express complex type relationships (again, possible because it forgoes soundness). I like programming in TypeScript also, and also miss its features when programming in C#. I doubt a language that combined C# and TypeScript would be very nice, these languages go in different directions to good effect, but they are not compatible directions.

Re: TypeScript please give us reflection/runtime types

#70
What I really miss is a way to extract type information directly from the compiler. Ie to have a ‘macro’ that takes a type as an input and returns a readable text or a json structure describing that type

It still wouldn’t be runtime typing, the compiler would just insert a constant wherever you use such a macro so I don’t think it would conflict with typescript’s goals. But it would make it a lot easier to build extra checks when deserializing data - or just give richer debug information.

But it would probably be hard for eg esbuild to support such a feature if tsc adds it. So I couldn’t use it anyway :)

Post reply on HN