That makes sense. I guess the only things that would be missed are `values()`, `entries()` and possibly `keys()` (if works works differently from Object.keys()) from module "@dict". At the very least, an `Object.entries()` should be introduced if we don’t get that module.

Polyfilling and trying out standard library modules should be easy enough in ES6. The module loader seems ready for resolving standard module IDs differently.

Axel

On Jan 20, 2014, at 2:48 , Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> I'm inclined to say this has missed the train for ES6.
> 
> That may be fine.  It seems like we would use a little more experience with ES6 modules before we tackle this.
> 
> Allen
> 
> On Jan 19, 2014, at 8:47 AM, Tom Van Cutsem wrote:
> 
>> I don't know of a more current one, but things have probably changed since nov. 2012 (the page's last edit). For instance, Proxy now lives in a separate @reflect module.
>> 
>> Regards,
>> Tom
>> 
>> 
>> 2014/1/19 Axel Rauschmayer <axel at rauschma.de>
>> http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard
>> 
>> Is this the most current document on the standard modules?

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140120/18e112b5/attachment.html>

That makes sense. I guess the only things that would be missed are `values()`, `entries()` and possibly `keys()` (if works works differently from Object.keys()) from module "@dict". At the very least, an `Object.entries()` should be introduced if we don’t get that module.

Polyfilling and trying out standard library modules should be easy enough in ES6. The module loader seems ready for resolving standard module IDs differently.