A few more questions about the current module proposal

Russell Leggett russell.leggett at gmail.com
Thu Jul 5 10:06:41 PDT 2012


Sorry I haven't gotten a chance to get into this thread sooner, let me
catch up a bit:

On Wed, Jul 4, 2012 at 2:56 PM, Jussi Kalliokoski <
jussi.kalliokoski at gmail.com> wrote:

> On Wed, Jul 4, 2012 at 9:13 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
>  wrote:
>
>> On Wed, Jul 4, 2012 at 12:29 PM, Jussi Kalliokoski
>> <jussi.kalliokoski at gmail.com> wrote:
>> >
>> > 1) How does the static resolution and static scoping behave when out of
>> the
>> > normal context. As an example if `import` is in an `eval()` call, what
>> would
>> > happen:
>> >
>> > var code = loadFromURL('http://example.org/foo.js') // content:
>> `import foo
>> > from "bar"`
>> > eval(code)
>> > console.log(foo) // ???
>>
>> First, what does `loadFromURL` do?  That looks like sync IO to me.
>>
>
> Indeed it is, to simplify things. Let's pretend it's a function that gets
> the text contents of a URL.
>
>
>> > Would this example block until the module is resolved and loaded? Would
>> it
>> > throw? What happens, exactly? As my $0.02 goes, I think it's a bad idea
>> to
>> > ban import in eval.
>>
>> Second, it depends on whether "bar" is a previously-loaded module.
>> For example, if "bar" is a library provided by the host environment,
>> such as the browser, then everything will be fine, and the code will
>> import `foo` successfully.  If "bar" is a remote resource, this will
>> throw -- we're not going to add synchronous IO to `eval` (or to
>> anything else).
>>
>
> So basically, eval()'ing something acquired via XHR would no longer give
> the same result as it does if the same script is in a script tag? Suffice
> to say I disagree strongly with this choice, but I'm sure the rationale
> behind this choice is strong.
>

So I guess my take on it is that any import statement should be illegal
inside of eval. Looking at the proposal, that doesn't sound like it,
though. Let's take the "loadFromUrl" out of the equation.

    import foo from "baz"
    var code = 'import foo from "bar"';
    eval(code);
    console.log(foo);

There is a reason why import got special syntax, and it wasn't just so that
it would be easier to type. Putting it inside eval eliminates any ability
for static analysis to happen upfront during the parse before actually
executing. The import dependency cannot be seen, and in this case there is
a collision on "foo" which should have been detected at compilation time. I
can think of a dozen other reasons why imports should not be allowed in
eval, but that's just one which seems like a pretty clear problem.

On Thu, Jul 5, 2012 at 8:56 AM, Kevin Smith <khs4473 at gmail.com> wrote:

>
> One question, though:  branching on the file extension, as above, will not
> generally work.  The source code might be served through a URL that does
> not have a file extension.  On the web though, we'll generally have access
> to a Content-Type header.  In the current design, there's doesn't appear to
> be a way to get that information.
>

This makes a lot of sense to me. Great idea.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120705/6b511366/attachment-0001.html>


More information about the es-discuss mailing list