'new' keyword

[liuhenry4428]

TypeScript use case: img[i] = new Image();

[sampsyo]

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]

I like this idea a lot! I think this principle should also be used for TypeScript features that haven't been implemented yet but should be (such as #96, cause duh), since it centralizes the uses of each feature so they can be replaced as Gator supports them.

I do think it's still important to create issues for these features and support some of them; otherwise I could imagine this sort of design getting out of hand. This issue in particular seems to provide an example of a potential metaprogramming/design explosion. With Gator slated to support structs (see #63), being able to create objects/classes in some way seems important to avoid type-checking complexity around internal variables and functions. Graphics in general just has so much need for object structure (such as when bundling light information), that it seems way too complicated to not support.

I do agree with something like #99 not getting explicit support; however, I think I'll keep them as an issue (I'll tag those with wontfix), since they document cases where we intend to use internal "hacks" without compiler implementation.