And now we also have a bugzilla product into which you can report issues found
in the specification:
https://bugs.ecmascript.org/enter_bug.cgi?product=ECMAScript%20Globalization%20API
Items that may need discussion among a larger audience should still go to
es-discuss@mozilla.org.
Thanks,
A guide and background article is now available:
http://norbertlindenberg.com/2011/11/ecmascript-globalization-api/index.html
Regards,
Norbert
On Nov 2, 2011, at 0:10 , Norbert Lindenberg wrote:
A working draft of the ECMAScript Globalization API Specification for review
at the November TC
On 3 November 2011 01:12, David Herman dher...@mozilla.com wrote:
ES6 modules are not extensible, for a number of reasons including
compile-time variable checking. But of course API evolution is critical, and
it works; it just works differently. Monkey-patching says let the polyfill
add the
Yes, good point about loaders. I would like a standard HTML way of specifying a
loader to use, so you could simply say:
meta loader=polyfill.js/
and from then on your clients don't have to change a thing.
Dave
On Nov 3, 2011, at 2:00 AM, Andreas Rossberg wrote:
On 3 November 2011 01:12,
Can loaders be composed (e.g. to use several polyfills at the same time)? One
might be able to chain them in some fashion.
Yes, good point about loaders. I would like a standard HTML way of specifying
a loader to use, so you could simply say:
meta loader=polyfill.js/
and from then on
A working draft of the ECMAScript Globalization API Specification for review at
the November TC 39 meeting is available at
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
There are still a number of open issues, and the algorithms still need
significant work, but the
The draft has the following:
*6 The Globalization Object*
The Globalization object is a single object that has some named properties,
all of which are constructors.
The value of the [[Prototype]] internal property of the Globalization
object is the built-in Object prototype object specified by
We were told (I think by Allen) that setting [[Extensible]] to true would
conflict in some way with ES6 modules. I do agree it's a big restriction to
set it to false given how JavaScript works today.
So the question is - are we going to have problems with ES6 Modules is we
set this property to
On Nov 2, 2011, at 3:00 PM, Nebojša Ćirić wrote:
We were told (I think by Allen) that setting [[Extensible]] to true would
conflict in some way with ES6 modules. I do agree it's a big restriction to
set it to false given how JavaScript works today.
So the question is - are we going to
On Nov 2, 2011, at 3:00 PM, Nebojša Ćirić wrote:
We were told (I think by Allen) that setting [[Extensible]] to true would
conflict in some way with ES6 modules. I do agree it's a big restriction to
set it to false given how JavaScript works today.
So the question is - are we going to
On Nov 2, 2011, at 4:09 PM, Allen Wirfs-Brock wrote:
Ideally, the globalization support would manifest as a global (or properties
on an existing global) in ES5 implementations and as a module in ES.next. Do
we know how to actually make that work?
What we did talk about was exposing the
My main concern at the moment is ES5. It seems that best practice is to
declare [[Extensible]]:true, which would in turn avoid conflicts with
pre-existing globals and let developers append new functionality to
Globalization. We can deal with modules in the future revisions if
necessary.
02.
On Nov 2, 2011, at 4:51 PM, Nebojša Ćirić wrote:
My main concern at the moment is ES5. It seems that best practice is to
declare [[Extensible]]:true, which would in turn avoid conflicts with
pre-existing globals and let developers append new functionality to
Globalization. We can deal with
I think we probably have an interesting question for Dave and Sam about how
to support version evolution of modules. Is there a module equivalent of
monkey patching. What if we have an implementation that exposes a V1 module
(particularly a built-in module) and code that depends upon upon
14 matches
Mail list logo
