No subject

Thu Feb 11 18:09:36 PST 2010

referencing will not be supported?<br>
Right, the modules importable through this syntax would<br>
thus be considered &quot;pre-registered&quot; in some sense.<br>
I&#39;m still a little confused by the rules here, but assuming a<br>
naive loader implementation, what would the following result<br>
in? (bonus points for describing how you envision a made-up<br>
setup process):<br>
 =C2=A0module Tokenizer { ... }<br>
 =C2=A0// Main.js<br>
 =C2=A0import compiler.Tokenizer.*;<br>
I don&#39;t find a definition for &quot;module body&quot; in your strawman.=
Are you meaning that <a href=3D"" target=3D=
"_blank"></a> above<br>
is organized as:<br>
 =C2=A0function stringify...<br>
 =C2=A0function parse...<br>
or as<br>
 =C2=A0export function stringify...<br>
 =C2=A0export function parse...<br>
 =C2=A0(although this is invalid according to the grammar)<br>
or as something else?<br>
It would be nice with a unified syntax for module &quot;sub-addressing&quot=
that looks the same both when loading a new module or when<br>
aliasing an existing module.<br>
Two random thoughts on this:<br>
- I think it would be suitable with some special marker when<br>
 =C2=A0addressing built-ins, as<br>
 =C2=A0 =C2=A0module JSON =3D load &quot;JSON&quot;;<br>
 =C2=A0might as well be used for relative addressing to the<br>
 =C2=A0 =C2=A0./JSON<br>
 =C2=A0application URL, which should issue an external request.<br>
- For the web it is probably not interesting to do this resolution<br>
 =C2=A0for anything else than built-ins and *one* external URL.<br>
 =C2=A0Providing a search path with multiple external URLs would mean<br>
 =C2=A0depending on hitting 404s as part of the load phase, which is<br>
 =C2=A0usually frowned upon.<br>
Best regards<br>
<font color=3D"#888888">Mike<br>
</font><div><div></div></div><br>----------<br><span><font color=3D"#888">F=
rom: <b>Sam Tobin-Hochstadt</b> <span dir=3D"ltr">&lt;<a href=3D"mailto:sam=
th at" target=3D"_blank">samth at</a>&gt;</span><br>
Date: Thu, May 20, 2010 at 2:12 PM<br>To: Mike Wilson &lt;<a href=3D"mailto=
:mikewse at" target=3D"_blank">mikewse at</a>&gt;<br>Cc: =
es-discuss &lt;<a href=3D"mailto:es-discuss at" target=3D"_blank">=
es-discuss at</a>&gt;<br>
</span><br>Thanks for all your detailed feedback!<br>
Right. =C2=A0If this was allowed, then we&#39;d have the infinite chain of<=
modules Even.Odd.Even.Odd.Even and so on.<br>
First, I want to emphasize again that our ideas about offline JS are<br>
preliminary, and not intended for standardization. =C2=A0Different host<br>
environments can make different choices here. =C2=A0But on this example,<br=
we&#39;re envisioning that Main.js would import compiler.Lexer.Tokenizer.<b=
Or perhaps there would only be one module per file when implicitly<br>
loading modules from the file system, but that would probably be<br>
needlessly restrictive.<br>
The latter. =C2=A0We should think of the contents of json2.js as an<br>
anonymous module, which the client names using &#39;load&#39;.<br>
I agree, it&#39;s probably confusing for &quot;JSON&quot; and &quot;./JSON&=
quot; to mean<br>
radically different things. =C2=A0But staking out URL space for this seems<=
heavyweight and ugly. =C2=A0Is there a good middle ground?<br>
I think this is right in terms of how people should program on the<br>
web, but I&#39;m not sure that it should be standardized. =C2=A0Only allowi=
one external URL requires making a determination of what&#39;s external<br>
and what&#39;s built-in, and any one decision might not necessarily be<br>
right for every host environment.<br>


More information about the es-discuss mailing list