I guess Kevin has some same concerns with me.
The four things point to one question: What should we do with the old
ES3/ES5 libraries after we have module?
(please correct me if you didn't mean that.)
ES3/ES5 libraries might be in more than one files and there are no
“export” and import in it.
On 29 August 2012 18:39, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
There are been various previous runs at defining syntactic support for using
unique/private names. They all run into either real or hypothetical
usability issues that blocked adoption. One consistent area of concern has
On Fri, Aug 31, 2012 at 3:16 PM, 程劭非 csf...@gmail.com wrote:
I guess Kevin has some same concerns with me.
The four things point to one question: What should we do with the old
ES3/ES5 libraries after we have module?
(please correct me if you didn't mean that.)
ES3/ES5 libraries might be in
From: Alex Russell
Sent: Thursday, August 30, 2012 7:44 PM
To: ste...@stevensanderson.com
Cc: es-discuss@mozilla.org
Subject: Re: Object.observe and observing computed properties
On Wed, Aug 29, 2012 at 11:09 AM, Steve Sanderson fla...@gmail.com wrote:
Knockout developers are used to this
From: Rick Waldron
Nit: Object.makeBindable sounds like: prepare this for bindability,
but bind is already a concept in the language, where
Function.prototype.bind creates a new function object from an existing
function object, but with a BoundThis as specified by the thisArg in
fn.bind(
What does it look like if you want to import more than one variables
from one module?
2012/8/31 Shijun He hax@gmail.com:
On Fri, Aug 31, 2012 at 3:16 PM, 程劭非 csf...@gmail.com wrote:
I guess Kevin has some same concerns with me.
The four things point to one question: What should we do with
Hi,
The i18n spec is currently lacking detail on the properties of Intl object. I
expected to see something like the following in the spec:
{[[Enumerable]]: false, [[Writable]]: true, [[Configurable]]: true}
Particularly, is it [[Enumerable]]? If so, what is the use case?
--
Marcos
Hi,
This is a bit of bike shedding Currently, the spec defines
resolvedOptions - which is using a noun for a function name. Generally
speaking, nouns should not be used as function names, only for
attributes/getters.
I would urge the function be renamed to resolveOptions(). Dropping the
Hi,
I have a strong concern about the i18n API throwing an exception when an
unknown value is given as part of the option parameter for a constructor or
function.
For example, if I do:
new v8Intl.DateTimeFormat(x, {year: long});
or:
x.toLocaleTimeString(en, {year: long});
I get in Chrome:
This is what Markus had to say (he implemented most of the collation for
ICU):
http://www.unicode.org/reports/tr10/#Avoiding_Normalization
Step 1 of the algorithm: http://www.unicode.org/reports/tr10/#Step_1
which has a note:
- Conformant implementations may skip this step *in certain
It takes a few steps to find the information, but I think the
Internationalization API spec together with the Language spec cover this:
Clause 8 of the Internationalization API spec says: The Intl object is a
standard built-in object that is the initial value of the Intl property of the
global
Actually, all options have to be resolved in the constructors, because the
functions returned by the compare and format getters also depend on the results
of the resolution process. resolvedOptions() just packages up the results in a
new object and returns that.
A correct description in verb
For comparison, quite a lot of ECMAScript function names are nouns, e.g.
Date.now, String.prototype.{substring, indexOf}, etc.
From: Norbert Lindenberg
Sent: August 31, 2012 12:16
To: Marcos Caceres
CC: es-discuss
Subject: Re: i18n API - resolvedOptions
Actually, all options have to be
OK, so the Unicode conformance question hinges on must be able to do versus
must do.
The question for ECMAScript then is whether we should stick with must do (the
current state of the specifications) or change to must be able to do.
The changes for must be able to do would be:
- In the
I think we could go either way. It depends on the usage mode.
1. The case where performance is crucial is where you are comparing
gazillions of strings, such as records in a database.
2. If the number of strings to be compared is relatively small, and/or
there is enough overhead
On Aug 31, 2012, at 12:53 AM, Andreas Rossberg wrote:
On 29 August 2012 18:39, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
There are been various previous runs at defining syntactic support for using
unique/private names. They all run into either real or hypothetical
usability issues
On 31 August 2012 19:39, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 31, 2012, at 12:53 AM, Andreas Rossberg wrote:
Two observations. First, IIUC, separate namespaces mean that I can _not_
write
let foo = new Name
o.@foo = 1
anymore. For first-class names, I would have to fall
I think #2 is far more common for ECMAScript - typical use would be to re-sort
a list of a few dozen or at most a few hundred entries and then redisplay that
list. #1 might become more common though as JavaScript use on the server
progresses.
So here's an alternative spec approach:
- Leave
Hi Marcos,
Thanks for the comments. Replies below.
Norbert
On Aug 31, 2012, at 7:17 , Marcos Caceres wrote:
Hi,
I have a strong concern about the i18n API throwing an exception when an
unknown value is given as part of the option parameter for a constructor or
function.
For example,
19 matches
Mail list logo
