TypeScript please give us reflection/runtime types • Hacker News Board

Re: TypeScript please give us reflection/runtime types

#121

Post by Nullabillity » Fri, Jul 07, 2023, 9:22 PM UTC

TheRealPomax wrote: post #105

tylerhou wrote: post #76

Earlier quoted context omitted.

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 wou…

Here's the thing though: if you wrote your TS properly, you don't need this and asking for it just highlights that you're not using TS the way it's meant to be used. The only place you need runtime type enforcement (when you're writing your own code in TS) is for validating third party data at the point where you're ingesting it into your own code. Once it's in there, it is type safe if you used TS to compile your co…

That boundary validation is where that kind of reflection would be useful! And it's a problem that (nearly) every useful application has to face.

Well that, and getting rid of the silly "must be able to strip types without processing them" design ideology would also enable stuff like typeclasses.

Re: TypeScript please give us reflection/runtime types

#122

Post by dang » Fri, Jul 07, 2023, 9:22 PM UTC

paulddraper wrote: post #3

Better title: TypeScript please give us reflection/runtime types AFAIK the best current solution is emitlDecoratorMetadata. [1] [1] https://www.typescriptlang.org/tsconfig#emitDecoratorMetadat...

Ok, we'll add that bit to the title above. Thanks!

Re: TypeScript please give us reflection/runtime types

#123

Post by andix » Fri, Jul 07, 2023, 9:22 PM UTC

moduspol wrote: post #113

TheRealPomax wrote: post #105

Earlier quoted context omitted.

Here's the thing though: if you wrote your TS properly, you don't need this and asking for it just highlights that you're not using TS the way it's meant to be used. The only place you need runtime type enforcement (when you're writing your own code in TS) is for validating third party data at the point where you're ingesting it into your own code. Once it's in there, it is type safe if you used TS to compile your co…

And presumably you need to also trust your third party libraries, unless you're also compiling them from TypeScript. Right? And even if you are--that might also involve ensuring their tsconfig.json is compatibly similar to yours. Otherwise the compiler might allow them to return null instead of the object they say they return, among potentially many other "gotchas" that are bound to appear. EDIT: Though I think I do…

Yes, you need to trust your third party libraries, better check them. Otherwise they may steal your data, inject XSS, mine cryptos, have memory leaks or faulty logic.

Re: TypeScript please give us reflection/runtime types

#124

Post by WorldMaker » Fri, Jul 07, 2023, 9:24 PM UTC

ragnese wrote: post #65

orangepanda wrote: post #14

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…

From my understanding, namespaces are on the same list with enums of things that the developers regret ever adding to the language but can't take out without breaking old code. Namespaces also at least have the excuse of being a "necessary" jQuery-era "Production pattern" in the land before ESM was standardized and somewhat relating to the similar syntax sugar of import/export when generating AMD, UMD, and CommonJS modules.

So too are "experimental decorators" another thing that some of the developers seem to list as massive regrets. That example is even so much worse than namespaces because it wasn't justified by existing patterns used in Production JS at the time and that they even believed that requiring a compile-time flag with the word "experimental" in it would stop developers from using that compile-time flag in anything destined for Production usage. (Seriously, we all should shame the many projects/companies that did that.)

Re: TypeScript please give us reflection/runtime types

#125

Post by paxys » Fri, Jul 07, 2023, 9:26 PM UTC

Nullabillity wrote: post #117

paxys wrote: post #112

Earlier quoted context omitted.

I still don't see the point. There is a long list of libraries that do exactly this, and do it well enough. The author has linked to them himself. The overall benefit of this would be maybe slightly better syntax for these libraries (even that is doubtful, because plenty of them already have a `reflect ()` interface), but still zero runtime benefit. And getting it to be accurate for 100% of cases would entail exactly…

So now you're stuck writing for an awkward inner platform language rather than using the TS syntax itself.

What's this "awkward inner platform language"? They are asking for a `typescript.generateRuntimeType()` function to be native to the language. Well plenty of libraries provide exactly this syntax today. Here's tst-reflect: `const type = getType()`. Notice any difference?

Re: TypeScript please give us reflection/runtime types

#126

Post by theteapot » Fri, Jul 07, 2023, 9:27 PM UTC

TheRealPomax wrote: post #105

tylerhou wrote: post #76

Earlier quoted context omitted.

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 wou…

Here's the thing though: if you wrote your TS properly, you don't need this and asking for it just highlights that you're not using TS the way it's meant to be used. The only place you need runtime type enforcement (when you're writing your own code in TS) is for validating third party data at the point where you're ingesting it into your own code. Once it's in there, it is type safe if you used TS to compile your co…

> And we already have runtime validation libraries to cover that validation step. So many of them.

Did you read the article? I think that's the point. The premise is Typescript should be responsible for solution to runtime validation against Typescript not third party hacks.

Re: TypeScript please give us reflection/runtime types

#127

Post by [deleted] » Fri, Jul 07, 2023, 9:28 PM UTC

jxf wrote: post #91

paxys wrote: 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 exactly why simple, concise writing is essential, and their wall of text is...not it. I only skimmed this but felt it was clear. They're asking for TypeScript, as part of the type erasure, to emit the type information it has discovered about the types in a side channel to the emitted JavaScript. Think of, say, PDB files as an analogy. > They are really asking for a net new product which has very little to d…

[deleted]

Re: TypeScript please give us reflection/runtime types

#128

Post by andix » Fri, Jul 07, 2023, 9:29 PM UTC

WorldMaker wrote: post #87

Waterluvian wrote: post #38

Earlier quoted context omitted.

There’s a ton written about this if you search for “typescript enums.” I just finished removing them from a major project. Here’s a few of my personal notes: 1. They don’t play well with duck typing. (Eg. show me a subset of an enum) 2. They require an import every time you want to utilize them. 3. They are pretty wordy compared to union strings. 4. Their string value version encourages misuse as a key-value pair. 5.…

Another one: they conflate Type and (Locator) Instance in a unique way that just about nothing else in TS does. Those are two very different things with the same name with Typescript's (antiquated) enums. There are too many ways to accidentally import/redeclare/rescope the Type of an enum so that TS "knows" the Type, but because that type (generally) has the same "name" as the most likely (Locator) Instance it assume…

Thanks for putting into words why they just "feel" so wrong.

Re: TypeScript please give us reflection/runtime types

#129

Post by paxys » Fri, Jul 07, 2023, 9:30 PM UTC

wvenable wrote: post #92

paxys wrote: post #84

Earlier quoted context omitted.

There are plenty of projects that do the same for TypeScript (e.g. https://github.com/typescript-rtti/typescript-rtti ) and plenty that support some kind of runtime reflection, and overall emitting TS type information at compile time in some readable format is a pretty trivial problem to solve. The complicated part is on the other side – what do you do with this information? How do you get JavaScript engines to under…

You don't get JavaScript engines to understand it. You use a library.

So then...exactly how it is done today? TypeScript provides an API to get type info at compile time. Libraries write plugins to consume this type info and use it for runtime and custom validation. What changes in this new world?

Re: TypeScript please give us reflection/runtime types

#130

Post by thanzex » Fri, Jul 07, 2023, 9:30 PM UTC

TheRealPomax wrote: post #105

tylerhou wrote: post #76

Earlier quoted context omitted.

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 wou…

Here's the thing though: if you wrote your TS properly, you don't need this and asking for it just highlights that you're not using TS the way it's meant to be used. The only place you need runtime type enforcement (when you're writing your own code in TS) is for validating third party data at the point where you're ingesting it into your own code. Once it's in there, it is type safe if you used TS to compile your co…

Except for the fact that usually there is not just one single typescript agent working within itself, for which you don't need validation. There are many cases in which you need to verify some object, anything that does not come from your code i would argue is untrusted, I come across this almost daily, it would be absolutely fantastic to just have a way to check does this object conform to this type? Instead, i need to use some external dependency, effectively duplicate my type definitions and add yet another place to introduce bugs.