Hi Dave,
Sorry for the slow reply -- was sick....
On Thu, May 27, 2010 at 4:19 PM, David Herman <dher...@mozilla.com> wrote:
> Years of PL research and experience have demonstrated that explicit linking
> tends to be unwieldy and inconvenient.
>
That needs to be added to my reading list. Cite away! :)
> People can easily add version information to their modules with whatever
> protocols they like, and we don't need to enforce them. ...
>
People are already creating module systems with versioning information (see
CommonJS). We need to make the world safe for them.
module Even = load 'even.js' with { Even: Even, Odd: Odd };
> module Odd = load 'odd.js' with { Even: Even, Odd: Odd };
>
With concise object literals, would that not be:
module Even = load 'even.js' with { Odd };
module Odd = load 'odd.js' with { Even };
In my experience, explicit linking is the better-is-better solution that
> makes programmers' lives harder for not enough gain.
>
But didn't you hear? Worse is also worse:
http://dreamsongs.com/Files/worse-is-worse.pdf
>From the article: "This advice is corrosive. It warps the minds of
youth." The last thing we want to do is warp the minds of youth. That task
we leave to the youth themselves.
* * * * *
But seriously: I am not *necessarily* suggesting explicit linking (however
defined). I am pointing out the necessary consequences of a dangerous design
that promises more than it can deliver.
> == 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).
>
Once again: the crucial issues are (a) predictable semantics without risk of
accidental clashes; and (b) making the world safe for versioning and other
such schemes for which CommonJS is already discovering the need.
I think we're doing pretty well on the (b) front, fwiw: I'm certainly
keeping it in mind as I look at your loader proposal, and so far things are
looking pretty good.
As for (a), if no *promise* is made that the "same" thing is loaded, then
it's no problem if that's not the case. So if loading returns a code-level
object which can then be instantiated with concrete parameters, and if the
contract of the code-level object is that it is, in general, loaded freshly
every time, then there is no confusable contract.
I suspect that this will induce a discussion about the relative merits of
explicit vs. implicit linking, which would be premature at this point.
Rather, in a separate message, I'll elaborate a little on Solution 2 from my
original post, as colored by Kam's feedback. This solution implements
implicit linking, but in a way that I think highlights some important
issues.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
