Just saw this tweeted:
http://slexaxton.github.com/Jed/
Wondered if anyone has any reactions. We have a Globalization API
rushing to standardization while libraries to do some of what it does
exist on github.com. It seems to me we ought to look at the latter while
finalizing the former -- if not actually interact with developers using
the latter more.
/be
Nebojša Ćirić <mailto:[email protected]>
January 20, 2012 2:38 PM
Thanks to Waldemar the meeting notes related to intl work were already
posted to the list. I would like to expand them, and restart
discussion on couple of remaining issues.
Testing
* We got ECMA number allocated to us (402) so we can use it for
testing infrastructure and any future needs.
* Talked to David Fugate about where to put the tests and how to run
them without affecting ES5 tests.
* Interested parties should ask for access to the test262 repository
(follow these instructions
<http://wiki.ecmascript.org/doku.php?id=test262:submission_process>).
* We need bugzilla entry for intl work for testing (we already have
one for the draft)
* Mr. Istvan pointed out that we may need to produce TR (one page)
that points to the tests. It's not gating on our progress.
Requirements for March meeting
* Draft ready and reviewed by TC39 members
* Two distinct implementations and testing in place
Microsoft and Google representatives stated that they could have
implementations ready by given deadline (barring large changes to the
current spec).
We are working on updating the draft and introductory document and
should have them ready for the review soon.
We started work on testing, but will need time to tell how quickly we
can progress there.
General
Going back to module vs. global object discussion. General agreement
was that we should pick a global name and work with that, then use
modules when they are ready, but that we should wait for Brendan to
pitch in before making a final decision. Most of the group was for
shorter name i.e. "intl" if it doesn't introduce conflicts.
The reason for this discussion was the current state of the module
spec, i.e. it's not clear yet where load/loaded will reside (not
everybody agrees on Object.system). In order to produce an
implementation by March and have draft accepted we do need to decide
rather soon on this.
Range vs. TypeError discussion. We eliminated ValueError proposal
from our spec and decided to use RangeError. A "fierce" discussion
followed and I think the final decision was to keep using RangeError.
--
Nebojša Ćirić
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
