Module Loader Comments

Kevin Smith khs4473 at gmail.com
Thu Mar 14 11:03:40 PDT 2013


> The way to invoke the default behavior will be to just return
> `undefined` from a hook (or fulfill with `undefined` for the fetch
> hook).


That's one way to do it.  It doesn't allow the overrider to do any
transformation on the result though.  If the overrider can explicitly call
the default behavior, then source translation could just be done from
within the fetch hook.

We'll be updating the wiki in the next week or two with these
> sorts of issues.
>

The sooner the better!  Modules are (IMO) the most important new feature of
ES6 and it's getting close...

- It ought to be possible to override the translation behavior without
> mucking with fetching.  Coffeescript translators don't need to perform
> their own fetching.
>

First, if the default behavior is explicitly invoked (as opposed to
implicitly by returning undefined), then fetching doesn't really have to be
mucked with.

Also (and this is a separate point), I don't see how in the current design
a CoffeeScript translator could be implemented as a custom loader.  As far
as I can tell, all loaders encapsulate their own module instance table.
 For CoffeeScript, you want the JS module instance table and the CS module
instance table to be the same.  Is there a way to have a custom loader
share an instance table with another loader, then?


> - calls to `eval` go through the translate hook, but not through the
> fetch hook, since there's nothing to fetch.
>

So we're going to have eval execute arbitrary languages other than
javascript?  I didn't realize this...  I'm going to have to think on that
for a while.

Thanks for debating, BTW!

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130314/4cc3ec55/attachment.html>


More information about the es-discuss mailing list