ModuleImport
C. Scott Ananian
ecmascript at cscott.net
Fri Jun 27 12:26:11 PDT 2014
On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg <rossberg at google.com>
wrote:
> I think you are missing the central problem. If imports/exports are to
> be statically checked, then module bindings, their exports, and their
> uses have to be statically recognisable and analysable. That prohibits
> intermixing "proper" modules with other random objects.
No, it means that your checker will only work with 'proper' modules. The
linter can easily have a white/blacklist to handle oddball cases.
You argue that throwing out checking is fine, i.e., you are arguing
> for the second goal, and against the first. But others disagree.
>
No. I believe that *allowing the user (or module author) to selectively
ignore* the checking (for example, by using a default import of an object
which is not a module). You seem to be missing my fundamental point: this
is not a dichotomy. You can check many imports, even if you can't check
all. If the module author chooses to export a function instead of an
object, you can't check the imports of *that one module*. Use a different
module if that bothers you!
No, the importers have no choice, they have to go with whatever the
> module provider picked.
The importers have the choice to use a different module (or fork the
module, or use a transpiler, or...).
The module author has the choice to re/structure his module to allow lazy
binding/checking *iff the users demand*.
> The hybrid, best of both worlds approach you seem to
> have in mind is technically impossible, unfortunately.
>
I look forward to a technical proof then. You have not yet provided that.
--scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140627/6a412df2/attachment.html>
More information about the es-discuss
mailing list