It would read nicer (and be easier to explain the system to a beginner) if we didn't have to prefix all Reify functions with "reify.".
Pros:
Less verbose code.
No need to explain the concept of modules/namespaces to beginners.
Cons:
It introduces the possibility for a naming conflict between a Reify type and a third party library.
In order to implement this, we would want to run the TypeScript compiler on the Reify interface ".ts" files during the build phase. We would have it produce a ".d.ts" file as well as a ".js" file. We would pass the ".d.ts" file into the embedded/wrapped TypeScript Compiler by appending it to the default library source. We would pass the ".js" file to be pre-loaded by the Reify-runtime before loading any modules, which also gives us the opportunity to create a snapshot of the implementation as well.
Things were pretty bad before, but it's much better now, and while we still have "h." in front of a lot of things, it's not too bad and kind of makes sense, so it'll probably stay, and this can be closed out.
Currently we have code like this which includes frequent references to "reify.":
It would read nicer (and be easier to explain the system to a beginner) if we didn't have to prefix all Reify functions with "reify.".
Pros:
Cons:
In order to implement this, we would want to run the TypeScript compiler on the Reify interface ".ts" files during the build phase. We would have it produce a ".d.ts" file as well as a ".js" file. We would pass the ".d.ts" file into the embedded/wrapped TypeScript Compiler by appending it to the default library source. We would pass the ".js" file to be pre-loaded by the Reify-runtime before loading any modules, which also gives us the opportunity to create a snapshot of the implementation as well.