brendan at mozilla.com
Mon May 17 11:07:00 PDT 2010
On May 17, 2010, at 10:30 AM, Kam Kasravi wrote:
> Thanks Mike, David.
> I agree with the conclusion that regex probably isn't the best way
> to tackle these problems.
> I'll summarize the use cases since it may apply in later
> 1. Is it possible to import parts of a module to avoid potentially
> large network payloads?
It's modules all the way down. You only import what you specify from
the module, but that doesn't affect downloading or indeed express the
module dependency -- the dependency comes from module declarations
creating bindings first, before any import from the module via its
Network payloads are induced by URL requests that miss the HTTP-rules-
based cache. MRLs are not URLs, however, so there's an opportunity
here to coalesce load requests. See below.
> 2. Is there syntax that would allow the server to group or
> concatenate delivery of multiple modules within one request?
This is a good question. The grouping of modules for download should
be decoupled from how one declares modules, to avoid mixing concerns
and requiring refactoring or rewriting just on account of repackaging.
Module declarations allow ahead of runtime loading, but they don't
help coalesce requests.
Coalescing requests (for some value of request) could be pushed down a
layer, not specified as part of the ECMA-262 language. This serves the
decoupling requirement. Is it enough? A while ago Allen wrote about
separating "configuration management":
Part of this was about version selection, but part of it was about
"assembly" structuring. It seems worth working through this, both with
a real implementation of simple modules, and with some thought
> From: David Herman <dherman at mozilla.com>
> To: Mike Shaver <mike.shaver at gmail.com>
> Cc: Kam Kasravi <kamkasravi at yahoo.com>; Brendan Eich <brendan at mozilla.com
> >; P T Withington <ptw at pobox.com>; es-discuss Steen <es-discuss at mozilla.org
> Sent: Mon, May 17, 2010 8:22:52 AM
> Subject: Re: modules proposal
> > For this, I would rather let the exporter define named export lists,
> > so that there's better future proofing. I would hate to be the
> > adding something to the SVG module knowing that there were a bunch
> > regexps floating around the web that might cause me to clobber
> > something unexpected.
> This gets to my main issue with regexps (aside from the YAGNI
> aspect) -- it puts too much significance into variable names, and
> becomes a refactoring hazard.
> > ("*Filter*" isn't even a legal regexp, so they'd get a compilation
> > error, but when you have to write SVG..*Filter.*, I think it gets to
> > be pretty unwieldy.)
> FWIW, you could distinguish this with the regexp syntax, for example:
> import SVG./.*Filter.*/;
> import /.*Filter.*/ from SVG;
> But ... um, well, yeah.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss