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 get it...the syntax is way harder when your language isn't basically a pre-parsed AST. But rust does it.
TypeScript imposes more detailed typing onto JS objects. It makes sense to ask the question: can the type imposed by TS onto a JS object be reified as a run-time object?
It could be, but maybe the use cases for that can be solved in another way that don't require the type system at run-time.
The good news is that static type is, well, static. All the objects of the same type can share a pointer to the same type metadata. The overhead is thus not necessarily huge: one extra property to initialize when an object is created.
The generated TS code has to carry the run-time support routines for the type stuff though.
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.
If ECMAScript had macros such that TypeScript could be a library, people would still ask the question: can we attach the type object manipulated by the library to the objects?
If ECMAScript had macros, page load times would skyrocket. ECMAScript and/or browsers would have to define a way to distinguish JS-with-macros files and embedded scripts from plain old JS that doesn't require expansion.
Any JS code bases with complicated macros that take time and memory to expand would have to be expanded by the developer and shipped expanded. So, back to the same model as TypeScript.
I beg to differ. There's a world of difference between:
1. a standardized feature with an official spec, which is subject to debate among the community, and of which it's viable to have multiple competing implementations; vs
2. a proprietary product that presents itself to be a superset of the core language (but isn't), is peddled by a single multinational, has a single implementation designed by an unaccountable elite in the employ of said multinational, which just so happens to be the original Dumbing Down The Computer Company
>If ECMAScript had macros, page load times would skyrocket.
>ECMAScript and/or browsers would have to define a way to distinguish JS-with-macros files and embedded scripts from plain old JS that doesn't require expansion.
If you introduce them today by way of a polyfill, maybe. I'm not necessarily advocating for introducing native macros to ECMA-262 at the present juncture. But I can't help speculating what would've happened if they had caught on.
If they were introduced at the point in history when people were first realizing transpilers were a thing; or designed into the language from the start; or a pre-existing metaprogramming-aware language was used in browsers, instead of Eich designing in 10 days an entire new language under the constraint that it also has to be an ad for Java - who knows where we would be as a civilization? What do you think?
What're you talking about? JS has had macros since the dawn of this world. Just eval(anything). For example eval(tsc("function f(x: number): number { return x + 1}")). Easy!
Seems like a huge waste.