ModuleImport

Kevin Smith zenparsing at gmail.com
Mon Jun 30 16:06:15 PDT 2014


>
>
>> - Mutable bindings
>>
>
> As far as I know, this is not something JS developers understand. What is
> it and what makes it an advantage?
>

Since imported bindings are just aliases for variables over in the
originating module, changing the value of that variable in the exporting
module will change value of the corresponding binding on the import side.

This is important for circular dependencies, because an imported binding
needs to get updated when the initialization phase runs to completion.

Outside of circular dependencies, I don't know.  I'm sure someone can find
a good use case for it : )


>
>> - Compile-time optimizations for "module.member" expressions
>>
>
> Is this known to be significant and fundamental? As in there is no way to
> achieve this optimization with the other format? Seems to me that the
> compiler introduces the getters and thus can inline them.
>

If there is no module object overwriting, then I suppose it could be
inlined.  If you allow overwriting, then you would need the further
restriction that you cannot import from overridden module objects.


>

>> The advantage of 1 only appears if we allow module object overwriting.
>>
>
> Concretely you mean monkey patching module objects in the importing code?
> Or?
>

I mean something equivalent to `module.exports = whatever`, where the
object stored in the registry was replaced by some arbitrary,
user-specified object.


>
>> The interoperability question is therefore of central importance.
>>
>
> Based on other discussion on this point, it seems like
> module-as-named-bindings can interoperate with CJS and AMD except perhaps
> in some unusual cases. Clarifying these cases would help.
>

As Scott and I pointed out, unless you have module-object overwriting (or
default exports), then you have to use some arbitrary name for CJS modules
that use the `module.exports = x` idiom.  And that's the only real
advantage of the module-as-object semantics.  In fact, it doesn't really
fly without it.


>
> To me, these two lists are pretty darn small compared with the overall
> advantages of modules.
>

So we should just pick a core semantics and get on with it?  I agree, but
we have to decide whether module-object-overwriting is a design requirement
or not.

To sum up, the strongest advantages are:

Option 1A (modules are regular objects which can be overwritten):  Possibly
better interoperability with CJS modules

Option 2 (modules as named remote bindings): Better support for circular
dependencies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140630/4c515683/attachment-0001.html>


More information about the es-discuss mailing list