Node.js, TC-39, and Modules
James M Snell
94922

really? is it such a complicated issue?

scalar data types group values of the same “kind”.
data structures group data together.
functions group operations together.
objects group related data and functions together. 
prototypes or classes group together the objects of the same structure or “kind”. 
files group together related objects and prototypes (or perhaps prototype constructors).
repositories group together related files. 
everything is a sort of container.

there is indeterminacy at all of these levels. in the code there are access operations and methods and ways to tell if the containee is contained in the container. try/catch tests for whether evaluation of a block contains an exception of a certain sort.

certainly standards efforts bring order to the multiple possible approaches to doing a particular thing that might or do exist. it might be a good idea at some point, however, to start making decisions about this alleged “order” in a standard way. so for example, why not deal with the indeterminacy of symbols in a file in the way that we deal with the indeterminacy of what is in an array? a file, by all philosophical accounts, should be an object containing a string or even containing all its component js objects. in the former case the file object would need to expose all the “assimilation” operations involved in “require”. in the latter case a file is in some sense pre-assimilated with all of its components already available.

given the baroque, chaotic way in which we develop software these days, a certain economy of concepts might be helpful. javascript is a beautifully elegant and compact way to specify imperative computation. why make it more complicated than it has to be?

as far as i know there is no standard way for a browser to tell a web page what parts of the current html/css/js standard it implements. there are only destructive tests. whether or not concurrent evolution of browser implementations and web standards is a good idea, it is the reality. we don’t care enough about this issue to create a “bill of materials” or “configuration” standard. we just let the entire web dev community wade through the nondeterminism of whether the browser implements the capabilities the page requires. arguing about whether to use a lexical/static approach or a dynamic approach to module symbol nondeterminism seems unimportant considering in that, in real terms, there is no standard for browser environments.

in any case a standards group should justify why its chosen approach to dealing with the nondeterminism of whether a module contains a symbol needs to be different than how a similar nondeterminism was addressed in a similar part of the same execution environment. and if it is justified then we need to go back and re-examine how to deal with the issue in the older parts of the standard. (“yes, toto. requiring container contents to be statically determined *is* ridiculous!” :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.