Module Loader Comments

Sam Tobin-Hochstadt samth at
Thu Mar 14 11:25:23 PDT 2013

On Thu, Mar 14, 2013 at 11:03 AM, Kevin Smith <khs4473 at> wrote:
>> 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.

That's why for several of the hooks, we plan to provide to the hook an
explicit value which is what the default would do.  For `translate`
this isn't needed, since the default is not to transform, and for
`fetch` browsers already provide ways of doing remote fetching.  I
don't think we want to force engines to reify these operations as new
JS functions.

>> 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...

Glad you're excited about modules.

>> - 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?

For this use case, you'd probably want to just modify the default
System loader to understand Coffeescript, via file extension
detection, AMD-style plugins, or some other mechanism.

If you want a new loader, you'll have to explicitly share the modules
that you want to share.  But the point of new loaders is to have the
distinct table.

>> - 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.

For Coffeescript, it's easy to actually translate `eval` calls.

The more important reason to handle `eval` in a loader is so that if
you're enforcing some invariant on code executed in a specific loader,
you don't want the code to be able to escape that invariant via

> Thanks for debating, BTW!

Hopefully it doesn't need to be a debate. :)


More information about the es-discuss mailing list