Simple Modules and Current Modules
kris at sitepen.com
Thu Nov 4 11:18:34 PDT 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 11/4/2010 11:42 AM, Brendan Eich wrote:
> On Nov 4, 2010, at 10:20 AM, Kris Zyp wrote:
>> the entire design space. If that is incompatible, so be it. But
>> if the current proposal can desugar and provide a smooth
>> transition, why shouldn't it? So far I am not seeing the
>> essential incompatibility.
> I repeated these points in AMWB, to what I was afraid was an
> excessive degree. I guess it wasn't :-/.
> There is no way to "desugar" a require("foo") into a prefetch of
> that URI before the script in which the require call occurs has
> loaded and is being evaluated.
I was not suggesting desugaring into CommonJS require() calls. The
transport-style API I referred to actually works similar to the
interaction module loader API  in terms of providing a set of
dependencies ( uses a call to a load function), provides a callback
for executing the script when the modules dependencies are available
(like provideSource() call from ). Based on the fact this is
currently used mechanism in the simple modules proposal, it doesn't
seem impossible to use API that it is suitable for ES5 code to work
It may well be feasible to that deal with the issues I raised by
creating custom module loaders. Is that what you would recommend? The
options so far have felt awkward, but I could certainly be missing
something. My objection is really based on my inability to see how we
use this new system will work with a mix of modules written for ES5,
text-based resources, and so on.
> There is no way to remove the global object from the scope chain in
It is possible to write ES5 that doesn't access the global object.
Enforcing this as part of simple modules is awesome.
> It is currently difficult to control visibility of outer names as
> viewed by an externally-loaded module body.
> Arbitrarily complicated compilation or preprocessing is not
> I don't see why you came out swinging hard, with lots of words,
> against Harmony modules, if you now agree with Alex.
Sorry, I didn't mean to come across harshly. Scaling back was just one
of the options I suggested. There is certainly goodness in simple
modules. If simple modules are really usable with real web
applications, that is great. If it can't meet modern requirements, the
simpler building blocks of goodness should be extracted. I assume that
is not very controversial. I am definitely open to simple modules
being a part of future ecmascript, but right now the ROI hasn't
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the es-discuss