No subject
Thu Feb 11 18:09:36 PST 2010
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
--0050450142dbcb96f7048800e493
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Dave,<div><br></div><div>Sorry for the slow reply -- was sick....<br><di=
v><br><div class=3D"gmail_quote">On Thu, May 27, 2010 at 4:19 PM, David Her=
man <span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.com">dherman at mo=
zilla.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Years of PL research and experience have de=
monstrated that explicit linking tends to be unwieldy and inconvenient.<br>
</blockquote><div><br></div><div>That needs to be added to my reading list.=
Cite away! :)</div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">People can easily add version information to their module=
s with whatever protocols they like, and we don't need to enforce them.=
...</div></blockquote><div><br></div><div>People are already creating modu=
le systems with versioning information (see CommonJS). We need to make the =
world safe for them.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;">=A0=A0 module Even =3D load =
'even.js' with { Even: Even, Odd: Odd };<br>
=A0 =A0module Odd =3D load 'odd.js' with { Even: Even, Odd: Odd };=
<br></blockquote><div><br></div><div>With concise object literals, would th=
at not be:</div><div><br></div><div>=A0=A0 =A0module Even =3D load 'eve=
n.js' with { Odd };</div>
<div>=A0=A0 =A0module Odd =3D load 'odd.js' with { Even };</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">In my experience, explicit link=
ing is the better-is-better solution that makes programmers' lives hard=
er for not enough gain.<br>
</blockquote><div><br></div><div>But didn't you hear? Worse is also wor=
se:</div><div><br></div><div>=A0=A0<a href=3D"http://dreamsongs.com/Files/w=
orse-is-worse.pdf">http://dreamsongs.com/Files/worse-is-worse.pdf</a></div>=
<div>
<br></div><div><div>From the article: "This advice is corrosive. It wa=
rps the minds of youth."=A0The last thing we want to do is warp the mi=
nds of youth. That task we leave to the youth themselves.</div></div><div>
<br></div><div>=A0=A0 =A0 * =A0 * =A0 * =A0 * =A0*</div><div><br></div><div=
>But seriously: I am not *necessarily* suggesting explicit linking (however=
defined). I am pointing out the necessary consequences of a dangerous desi=
gn that promises more than it can deliver.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">> =3D=
=3D Solution 3: Forming a more generative Union =3D=3D<br>
<br>
</div>I didn't understand all this, but eliminating side effects in mod=
ules is not going to change the fact that when you load different bits, you=
get a different module. Solutions involving canonicalization are either go=
ing 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).<br>
</blockquote><div><br></div><div></div></div><div>Once again: the crucial i=
ssues 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.</div>
<div><br></div><div>I think we're doing pretty well on the (b) front, f=
wiw: I'm certainly keeping it in mind as I look at your loader proposal=
, and so far things are looking pretty good.</div><div><br></div><div>As fo=
r (a), if no *promise* is made that the "same" thing is loaded, t=
hen 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, lo=
aded freshly every time, then there is no confusable contract.</div>
<div><br></div><div>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=A0a separate message, I'll elaborate a little=
on Solution 2 from my original post, as colored by Kam's feedback. Thi=
s solution implements implicit linking, but in a way that I think highlight=
s some important issues.</div>
<div><br></div><div>Ihab</div><div><br></div><div>--=A0</div>Ihab A.B. Awad=
, Palo Alto, CA<br>
</div></div>
--0050450142dbcb96f7048800e493--
More information about the es-discuss
mailing list