On Thu, May 20, 2010 at 3:47 PM, Mike Wilson <mike...@hotmail.com> wrote: > Thanks for the detailed explanations, David. Here's a few follow- > up questions (with "done" questions snipped out):
Thanks for all your detailed feedback! > David Herman wrote: >> > | This allows cyclic dependencies between any two modules >> > | in a single scope >> > >> > 1) Is this to say that cycles are allowed, or not allowed, in >> > other scenarios? (f ex remote or filesystem-loaded modules) >> > <snip> >> Since MRL's and module names are distinct, there's no problem >> letting remote modules refer to one another, they just have >> to do so through agreed-upon names. For example: >> >> module Even = "http://zombo.com/even.js";; >> module Odd = "http://realultimatepower.net/odd.js";; >> >> By binding them both at the same level of scope, both even.js >> and odd.js can refer to Even and Odd. > > Agreed, but I was rather wondering about cases like: > > even.js > module Odd = "odd.js"; > ... > odd.js > module Even = "even.js"; > ... > > From other discussion I'm guessing this kind of circular > referencing will not be supported? Right. If this was allowed, then we'd have the infinite chain of modules Even.Odd.Even.Odd.Even and so on. >> > 3) Is Lexer.js required to contain exactly one module >> > declaration that must match the filename, or otherwise an >> > exception is thrown? >> >> The short answer is no: the contents are the body of the module. >> >> The long answer is that it depends on the module loader. > <snip> > > I'm still a little confused by the rules here, but assuming a > naive loader implementation, what would the following result > in? (bonus points for describing how you envision a made-up > setup process): > > // compiler/Lexer.js > module Lexer { ... } > module Tokenizer { ... } > ... > // Main.js > import compiler.Tokenizer.*; First, I want to emphasize again that our ideas about offline JS are preliminary, and not intended for standardization. Different host environments can make different choices here. But on this example, we're envisioning that Main.js would import compiler.Lexer.Tokenizer. Or perhaps there would only be one module per file when implicitly loading modules from the file system, but that would probably be needlessly restrictive. >> > In the "Remote modules on the web (1)" example we have: >> > >> > | module JSON = load 'http://json.org/modules/json2.js'; >> > | alert(JSON.stringify({'hi': 'world'})); >> > >> > 7) Am I understanding correctly that this is pointing to a >> > plain script (without module decls) which is wrapped inside >> > the JSON module we specify? >> >> It's a module body, which may contain nested module >> declarations, variable declarations, function declarations, >> statements, etc. > > I don't find a definition for "module body" in your strawman. > Are you meaning that http://json.org/modules/json2.js above > is organized as: > > function stringify... > function parse... > > or as > > export function stringify... > export function parse... > (although this is invalid according to the grammar) The latter. We should think of the contents of json2.js as an anonymous module, which the client names using 'load'. >> > In the "Static module detection" example we have: >> > >> > | // compiler tries each in order >> > | module JSON = load ('JSON' || >> 'http://json.org/modules/json2.js'); >> > >> > 10) Does this syntax mix module identifiers and MRLs? (the >> > 'JSON' item looks very much like a pre-registered module in >> > the module registry?) >> >> No, I was just positing some syntax for built-in MRL's. Maybe >> I should've written something like >> >> module JSON = load ('browser://JSON' || >> 'http://json.org/modules/json2.js'); >> >> but I didn't want anyone to think I was making some specific >> proposal for a new URL scheme or anything. > > Two random thoughts on this: > > - I think it would be suitable with some special marker when > addressing built-ins, as > module JSON = load "JSON"; > might as well be used for relative addressing to the > ./JSON > application URL, which should issue an external request. I agree, it's probably confusing for "JSON" and "./JSON" to mean radically different things. But staking out URL space for this seems heavyweight and ugly. Is there a good middle ground? > - For the web it is probably not interesting to do this resolution > for anything else than built-ins and *one* external URL. > Providing a search path with multiple external URLs would mean > depending on hitting 404s as part of the load phase, which is > usually frowned upon. I think this is right in terms of how people should program on the web, but I'm not sure that it should be standardized. Only allowing one external URL requires making a determination of what's external and what's built-in, and any one decision might not necessarily be right for every host environment. -- sam th sa...@ccs.neu.edu _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
