ModuleImport

[C. Scott Ananian]

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>