Hi Ihab,
Thanks for your thoughts on this. I'll just respond to what I understand to be
your main points.
> The problem is that, in the space of module names, the current Simple
> Modules strawman introduces a hazard of inadvertent name capture
Yes, implicit linking means that you can mis-link. In my mind, the questions
are how much of a hazard this really is, how much architecture it would require
imposing on programmers to address it, and what we lose if we do that.
Many of your suggested alternatives involve explicit linking. Explicit linking
certainly has its appeal: it lets you really say exactly what you mean. But
there are massive differences in the convenience of explicit and implicit
linking systems. Years of PL research and experience have demonstrated that
explicit linking tends to be unwieldy and inconvenient.
> The author cannot prevent this capture by controlling the
> environment of "two.js", nor can they foresee all possible
> environments such as "one.js" in which they may be embedded.
This is true. Now, it's true regardless of whether linking is implicit or
explicit. Either way, if the interface of the library changes in the wild to
add another dependency, its clients will likely break. The difference is that
with explicit linking it will necessarily fail whereas with implicit linking,
it might a) succeed, b) fail by not receiving a module binding, or c) fail
unpredictably by receiving the wrong binding. You said as much, I'm just
calling out the fact that no module system can change the fact that code
changes and programmers must deal versioning.
> I claim we must fail fast.
Failing fast would be nice, but I'm not convinced it's a necessity. We are not
trying to solve all versioning problems ever. People can easily add version
information to their modules with whatever protocols they like, and we don't
need to enforce them. There are plenty of over-engineered library systems in
use today, with crypto hashes and byzantine manifest formats etc etc, and
they're a nightmare for programmers.
> module One = load 'one.js' with {Drawing, jQuery};
This is just the kind of thing that looks nice with a single example, but as
soon as you put it into practice it gets out of control. Watch what happens
with even a trivial cyclic dependency:
module Even = load 'even.js' with { Even: Even, Odd: Odd };
module Odd = load 'odd.js' with { Even: Even, Odd: Odd };
Now imagine what happens to the combinatorics as your program size increases.
So then you either go down the road of trying to build a more expressive
language for wiring together the module graph (that way madness lies), or you
fall back to first-class modules-as-objects and programmers have to wire
together the module graph by mutating objects.
In my experience, explicit linking is the better-is-better solution that makes
programmers' lives harder for not enough gain.
> == Solution 3: Forming a more generative Union ==
I didn't understand all this, but eliminating side effects in modules is not
going to change the fact that when you load different bits, you get a different
module. Solutions involving canonicalization are either going to be too brittle
(e.g., trust the user to provide a single, stable set of bits for a given
canonical name) or too clunky (e.g., crypto-hashes, a total non-starter).
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
