Re: A few more questions about the current module proposal

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@...> wrote:

On Wed, Jul 4, 2012 at 9:13 PM, Sam Tobin-Hochstadt <samth@...> wrote:

On Wed, Jul 4, 2012 at 12:29 PM, Jussi Kalliokoski
<jussi.kalliokoski@...> 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@...> 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.