module path resolution

John J Barton johnjbarton at johnjbarton.com
Sun Mar 25 12:49:16 PDT 2012


On Sun, Mar 25, 2012 at 10:09 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

> Right. I also like Node’s idea of “global module names”, where a module
> name is a location-independent identifier, for a module that might be
> installed locally or globally.
>

I'm not sure what you mean by 'module names'.
http://wiki.ecmascript.org/doku.php?id=harmony:modules says:
  "External modules do not name themselves"

One effective strategy for referencing modules combines a variable path
with a well-known identifier. For example: 'array-strategies/SparseArray'.
The variable path, 'array-strategies', can be bound to a library path at
build or load time. The well-known name then selects the corresponding
entry from the library. This insulates the dependent module from path
changes but keeps the granularity of the redirection manageable.  The
variable-path may have lots of silly
../../ridiculousLongPathSegements/etc/etc, but this junk is isolated to the
main loading-control script.

Using single word names for module specifiers means every module has to be
redirected. Multi-word names require more understanding when writing the
redirection paths. Two parts make a good compromise.


> It might make sense to use a variable name for “relative to the HTML
> page”, e.g. "$BASE/methods/module". That would be more explicit than a
> convention on how to write the path.
>

Surely we would use JS functions or properties on the system loader rather
than string substitution right?

jjb


>
> On Mar 25, 2012, at 17:42 , Wes Garland wrote:
>
> On 25 March 2012 03:07, Axel Rauschmayer <axel at rauschma.de> wrote:
>
>> One thing that would be nice that we don't currently have is the ability
>> to load modules relative to the calling web page.  This is an oversight in
>> our loader.
>>
>>
>> I'm curious: What is the use case for that?
>>
>
> The case where you have two web pages loading mutually-shared JS -- or
> even one page using a lot of JS -- but not code you want to place in the
> globally-available library directory for whatever reason.
>
> We write web apps, and think of HTML files more or less as "programs".
> Local-dir modules are like extra .o files in a C program.  Module-dir
> modules are like libraries in /usr/lib.  The "main()" function is a module
> contained within the HTML itself, usually between </body> and </html>.
>
> Another use-case our loader doesn't address well is loading
> dynamically-generated modules.  These are modules whose source code is
> generated on the fly for whatever reason (e.g. they might emit information
> from a database, crypto secrets, etc.).  We have to do either
>
> require("../../methods/module")   /* brittle */
> or
> require("/" + window.location.hostname + "/methods/module")  /* annoying */
>
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
>
>
> --
> Dr. Axel Rauschmayer
> axel at rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120325/a8634032/attachment.html>


More information about the es-discuss mailing list