Closed nicolo-ribaudo closed 3 months ago
@guybedford I updated the spec. It turns out the TODO I left is already handled, but I left it as a NOTE since it's not trivial to notice.
One possible optimization - in the case where a deferred module has already successfully executed, we could provide the normal namespace instead of the deferred namespace without there being any observable difference. This could possibly be a spec note or even specified.
Guy and I discussed this in the modules call last week -- this cannot be done because the identity of the two namespaces is observably different.
This commit changes the behavior of namespaces obtained through
import defer
to re-throw evaluation errors even if the module is fully evaluated:The code above is now guaranteed to print
"Error!"
twice, and it doesn't depend on whether other modules already evaluated"module-that-throws"
.This is different from the existing behavior of namespace objects, so we have to use a different namespace object for deferred import:
Assuming that this module's body is evaluated due to a cycle (
module-that-throws
imports it, andmodule-that-throws
is the entry point), the code above will print"Error1!"
and not"Error2!"
. This means thatns1
!==ns2
. Namespace objects are still cached, so if youimport defer
the same module twice you will get the same namespace object.Thanks to this change, we can now also make "trying to evaluate a deferred module in a cycle" an error, rather than silently skipping its evaluation as done in #39. This ensures that a binding cannot be accessed during evaluation to then disappear as soon as the module is done evaluating with an error.
Fixes #41 cc @guybedford