On Thu, Mar 14, 2013 at 11:03 AM, Kevin Smith <khs4...@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 >> 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 `eval`. > Thanks for debating, BTW! Hopefully it doesn't need to be a debate. :) Sam _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
