sampsyo
commented
4 years ago Hey, @liuhenry4428—I was just having a few thoughts while reading over these new issues about language features to promote parity with TypeScript. It occurs to me that, while some of these would undoubtedly be convenient, it should certainly be a non-goal to completely replicate the entirety of TypeScript within Gator. That's way too much work! And the focus should be on making interesting geometric code expressible, not on writing any old random library interaction code.
Of course, we need a way to support the kind of code we want to write, and things like new Image() might be critical for some relevant examples. So allow me to suggest a workaround that might reduce the level of effort while providing a shortcut to writing realistic programs:
Put stuff like this in a runtime library. That is, make the TS backend produce code that import a custom library that you hand-write in TypeScript. The spirit could be similar to this glrt library I once wrote for a different compiler:
https://github.com/cucapra/braid/blob/master/glrt/glrt.ts
Then the Gator code that needs to do things like this can just call simple functions that do the TypeScript dirty work underneath. Or use simple type names to refer to complex TypeScript types, declared as type x = y type aliases in TS.
For example, there could be a function called new_image specifically for this. Or if you find yourself needing to write lots of class instantiation expressions, you could create a new_ function that takes the prototype as an argument. And for union types (#99) you could declare a type NullableTexture that is aliased to WebGLTexture | null under the hood.
I'd be interested in @Checkmate50's opinion on this stuff!
Checkmate50
TypeScript use case:
img[i] = new Image();