Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript please give us reflection/runtime types

github.com

Post reply on HN
Print view View original

131–140 of 287 posts

Re: TypeScript please give us reflection/runtime types

#131

Post by RyanCavanaugh »

tylerhou wrote: post #76
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…

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…

Not to be flip, but if it were really all this easy, we would have done it already.

There are dozens of questions you can throw at this code: What if the input's a union? What if it's a nested union -- how do you avoid combinatorial explosion? What if the input is a function -- how do you validate its parameter types using runtime information? What if the input is a conditional type? What if you're inside a generic function? The list is enormous and it quickly gets into "you've dug too deep and unleashed a Balrog" territory once you get beyond the primitives.

Re: TypeScript please give us reflection/runtime types

#132

Post by andix »

paxys wrote: post #125
Nullabillity wrote: post #117

Earlier quoted context omitted.

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?

Wow, i didn't know that this is already possible with type script. seems like there are transformers you can add to typescript that can implement it.

So type script more or less supports the feature they asked for. Just not bundled with the main package, but they provide the interface to get it done with 3rd party transformers.

Re: TypeScript please give us reflection/runtime types

#133

Post by tinideiznaimnou »

orthecreedence wrote: post #95

Reflection on a language that compiles to javascript? I don't get it. Why are people so allergic to macros?? Every stinking language that has compiled to JS has had a chance to do macros but they don't. Coming from many years spent in the lisp world, metaprogramming is this incredible feature that, in my experience, completely negates the need for runtime reflection while adding many other possibilities as well. I ge…

Preach, brother!

If only ECMAScript had a native macro system, TypeScript could be just a library - and I would have zero problems with its existence.

You're probably familiar with the following anecdote:

>Eich originally joined intending to put Scheme "in the browser",[4] but his Netscape superiors insisted that the language's syntax resemble that of Java.

JavaScript became the language that we all love to hate due to political, not technical reasons. Yet people look at me funny when I call out the TS/React monoculture as the blatant corporate power grab that it is.

Re: TypeScript please give us reflection/runtime types

#134

Post by scotty79 »

tylerhou wrote: post #76
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…

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…

If that's so much needed I wonder why there isn't a thriving ecosystem of pluggable typescript preprocessors that add whatever values based on types direcly to typescript source before compilation.

Re: TypeScript please give us reflection/runtime types

#135

Post by scotty79 »

DanRosenwasser wrote: post #120

Hey all, TypeScript PM here. I understand the desire here. Runtime type checking is often necessary for data validation, and we can see lots of libraries developed to help fill the gap here. But I think the fact that there are so many libraries with different design decisions is pretty indicative that this is not a solved problem with an obvious solution. We knew this going into the early design of TypeScript, and it…

Maybe official preprocessor plugins for TypeScript compiler could help?

I understand that everybody who needs it can already put their own preprocessor that generates runtime objects from type information before the code is passed to tsc for compilation.

But the effort is inconsistent and distributed.

If TypeScript officially supported pluggable preprocessor and plugin ecosystem for it some good solutions might get discovered.

Re: TypeScript please give us reflection/runtime types

#136

Post by cjdell »

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…

TypeScript does emit runtime type information through enums though.

Re: TypeScript please give us reflection/runtime types

#137

Post by scotty79 »

armchairhacker wrote: post #53
andix wrote: 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 (…

What if this macro could be expanded into valid typescript by preprocessor that runs before typescript compiler?

Re: TypeScript please give us reflection/runtime types

#138

Post by einrealist »

PaulHoule wrote: post #34
a_wild_dandan wrote: post #24

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.

Yeah but just because types exist at compile time doesn't mean they exist at run time. For instance with Generics in Java a List is the same as a List at run time, the compiler can enforce rules that let you add a String to one but not add a String to the other but the runtime has no idea. This has various negative consequences but it also let them retrofit generic collections on top of the old collection implementat…

Java's generic type information (aka parameterized types) is available at runtime through reflection.

Re: TypeScript please give us reflection/runtime types

#140

Post by kazinator »

Anything run-time has to come from JavaScript.

TypeScript is syntactic expansion layer over JavaScript.

"C preprocessor, please give me arrays that know how big they are at run-time. Oh, and access to the calling function's local variables!"

"Common Lisp defmacro, give me continuations usable anywhere!"

A macro layer can bring you the pie in the sky, but only (1) at some nonozero cost and (2) with additional representations that are not understood by regular code that is not in that framework.

Suppose a TypeScript type object is attached to every run-time object created in TypeScript. Firstly, those objects become more bloated and expensive to construct. [Edit: not really: all objects of the same type can have a pointer to the same meta-data which is created once]. They will need run-time support in their execution environment in order to have those type representations. Objects not created by TypeScript-generated code will not have anything like that attached to them, so places in the system where the two domains interoperate won't be able to rely on reflection; it will need a fallback for objects that don't do reflection.

I think serialization can be done without reflection. Because at the time when the static language is being processed, you could annotate certain types as requiring serialization. Then for those types, TypeScript would generate the marshaling routines.

Generating marshaling stubs from an interface language has been done in the C world for decades. It doesn't require any run-time types. The generated marshaling stubs just know how to walk objects of the type that they handle, and that's it.

It looks like in TypeScript, serialization is just punted to JSON, which is inadequate because when we are deserializing, we want to check that the JSON blob has a type and shape compatible with the TypeScript-level type. (Or even for that that type to be inferred in some way.) There are some libraries that try to do something in this direction like ts-serializer.

I think it's something you really want in TypeScript itself.

Basically round up the half-dozen or so use cases for reflection, and provide for all of them somehow without actual reflection. It's an X/Y problem. People really want to do Y (e.g. serialization), and believe that they must first solve X (have metadata in objects for reflection).

Post reply on HN