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'.
"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?
> 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 */
> require("/" + window.location.hostname + "/methods/module") /* annoying */
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss