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

271–280 of 287 posts

Re: TypeScript please give us reflection/runtime types

#271

Post by still_grokking »

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…

> Once it's in there, it is type safe if you used TS to compile your code to JS […]

To the extend that TS's type-system is unsound, and everything may crash at runtime at random anytime.

Re: TypeScript please give us reflection/runtime types

#272

Post by pjmlp »

andix wrote: post #269
pjmlp wrote: post #248

Earlier quoted context omitted.

This is the curse of guest languages, after the initial adoption pain everyone wants idiomatic libraries and pretends the underlying platform doesn't exist. Until they hit a roadblock caused by a leaky abstraction, that proves them otherwise.

Type script does a very good job not to hide the underlying platform. In it's essence it is just a development time linter and does not interfere with the JavaScript runtime at all (except enums). And I think that's actually the reason why it won the competition against Googles Dart. They even used Microsofts TypeScript for Angular instead of their own language Dart.

Indeed, and that is why the Typescript team is against any feature that steps away from that relationship.

Re: TypeScript please give us reflection/runtime types

#273

Post by Nullabillity »

paxys wrote: post #176
Nullabillity wrote: post #172

Earlier quoted context omitted.

But tst-reflect seems to work by effectively building their own forked tsc compiler.

No, they have a plugin into the typescript compiler which uses their API. tsc already exposes all of the info they need.

According to their (tst-reflect's) README, tsc doesn't support plugins. The plugin support comes from a fork called ttsc.

Re: TypeScript please give us reflection/runtime types

#274

Post by [deleted] »

vbezhenar wrote: post #86

The one downside of this proposal is faster typescript processors like esbuild. Right now they don't care about types, they just strip them from the code. It allows them to be very fast and provide fast feedback loop. With this proposal those tools must become extremely more complicated and probably they will just be as slow as tsc.

[deleted]

Re: TypeScript please give us reflection/runtime types

#275

Post by seanmcdirmid »

anonzzzies wrote: post #245
seanmcdirmid wrote: post #169

Earlier quoted context omitted.

TypeScripts goal of being just a layer over JavaScript led to its type system design being primarily productivity based: the goal was to make programming nicer, using types to get more performance wasn’t a goal or option. C#, and the CLR underneath it, were performance based, and the types feed into that. The reason they both are as they are is because of the environments they are meant to be used in. So ya, are you…

Yes, and I am aware of the histories, we just want (and need) something more now. Typescript still seems well positioned for this. Not many reasons you cannot fix this with a compiler flag (which is default off).

You would have to change the entire type system to make it C# like. TypeScript makes radically different assumptions about static typing than C# does. It also would be difficult to come up with a run-time type representation that was even sensical (due to unsoundness), let alone efficient. It isn't just a compiler flag that you want, its an entirely new language.

Re: TypeScript please give us reflection/runtime types

#276

Post by imbnwa »

RussBrown00 wrote: post #193

unpopular opinion, but this just fosters my opinion that TS people just don't understand JS at all. I wish TS would just die (another currently unpopular opinion). If you want runtime type safety, go use a different language and stop trying to ruin JS, it's already the messed up crazy cousin and it doesn't need to be in-bread anymore, it's perfect the way it is!

Only writer I know who discusses pure JS patterns that embrace those its dynamism is Raganwald Braithwaite[0]. For example, most people I know would call this hacky code[1], when this is just design patterns in idiomatic, non-Java/C#-constrained JavaScript. The truth, most devs desire intellisense and/or theorycrafting that comes with static types and compilers.

[0]https://raganwald.com/

[1]https://raganwald.com/2014/04/10/mixins-forwarding-delegatio...

Re: TypeScript please give us reflection/runtime types

#277

Post by PaulHoule »

einrealist wrote: post #138
PaulHoule wrote: post #34

Earlier quoted context omitted.

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.

Depends on the situation. If you just make an ArrayList (for some specific class X) you can call getClass() on that object and see it is an ArrayList but you cannot find out about the X.

If you make an ArrayListX that is not generic but extends ArrayList it is possible to see the type parameter that was extended, the same is true for implementations.

There are other kinds of type unerasure that you can use w/o the language supporting it explictly, such as you could pass the type parameter X.class into the constructor and put it in a field so that you could call some method like getContainedClass() and get a copy of X.

Now the introspection/reflection API does have support for talking about parameterized generic types that doesn't mean that information always exists at runtime.

I worked on a crazy project where I did a lot of fighting with ordinary types and parameterized types and unerasing types by rewriting the names of methods to avoid conflicts, if you have methods like

   A doSomethingTo(B)
   A doSomethingTo(C)
you can rewrite these to

   Expression doSomethingToB(Expression)
   Expression doSomethingToC(Expression)
but you can't have an overload that takes two differently parameterized expressions, this lets you write Java code in a lisp-like syntax that can be metaprogrammed on:

https://github.com/paulhoule/ferocity/blob/main/ferocity-std...

that project got me thinking a lot about the various ways types manifest in Java and I made the discovery that when you add Expression types you practically discover an extended type systems where there are many things that are implied by the existence of ordinary Java types.

Re: TypeScript please give us reflection/runtime types

#278

Post by consilient »

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…

In a language with a sound (or even sound modulo escape hatches) type system, I would agree. But Typescript can and will lie to you at compile time, and it's much harder to guard against this than it should be.

Re: TypeScript please give us reflection/runtime types

#279

Post by [deleted] »

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…

[deleted]

Re: TypeScript please give us reflection/runtime types

#280

Post by einrealist »

PaulHoule wrote: post #277
einrealist wrote: post #138

Earlier quoted context omitted.

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

Depends on the situation. If you just make an ArrayList (for some specific class X) you can call getClass() on that object and see it is an ArrayList but you cannot find out about the X. If you make an ArrayListX that is not generic but extends ArrayList it is possible to see the type parameter that was extended, the same is true for implementations. There are other kinds of type unerasure that you can use w/o the la…

I know how it works. The point of the topic was to have type information available, so we can use it for things like dynamic binding. No one asks for the runtime to be as strict as the type system (the compiler).

I like Venkat's presentations: https://www.youtube.com/watch?v=34oiEq9nD0M

BTW. I do not agree with the opinion in the topic. Since Typescript is compiled to something else (usually JS), I'd prefer Typescript to have proper annotations (there are "decorators") and compiler hooks and just use code generation for concerns like (de)serialization.

Post reply on HN