32960be0fb
This change redoes the way module exports are represented. The old mechanism -- although laudible for its attempt at consistency -- was wrong. For example, consider this case: let v = 42; export { v }; The old code would silently add *two* members, both with the name "v", one of which would be dropped since the entries in the map collided. It would be easy enough just to detect collisions, and update the above to mark "v" as public, when the export was encountered. That doesn't work either, as the following two examples demonstrate: let v = 42; export { v as w }; let x = w; // error! This demonstrates: * Exporting "v" with a different name, "w" to consumers of the module. In particular, it should not be possible for module consumers to access the member through the name "v". * An inability to access the exported name "w" from within the module itself. This is solely for external consumption. Because of this, we will use an export table approach. The exports live alongside the members, and we are smart about when to consult the export table, versus the member table, during name binding. |
||
---|---|---|
.. | ||
apply.go | ||
describe.go | ||
eval.go | ||
get.go | ||
mu.go | ||
plan.go | ||
verify.go | ||
version.go |