Module Loader Comments
samth at ccs.neu.edu
Thu Mar 14 11:25:23 PDT 2013
On Thu, Mar 14, 2013 at 11:03 AM, Kevin Smith <khs4473 at gmail.com> wrote:
>> The way to invoke the default behavior will be to just return
>> `undefined` from a hook (or fulfill with `undefined` for the fetch
> 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
>> 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
>> - 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
> 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