Re: Globalization API discussion
On Nov 21, 2011, at 9:52 AM, Allen Wirfs-Brock wrote:
> On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
>
>> On Nov 20, 2011, at 1:18 PM, David Herman wrote:
>>
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
>>>
>>> I'm of two minds about this. In the abstract, I agree with Brendan;
>>> fail-soft conceals bugs. But in reality, our destructuring logic is
>>> incredible fail-soft. Hardly anything in destructuring is treated as an
>>> error. And the syntax really *wants* to match the common pattern. So I'm
>>> torn.
>>
>> 1. Failing to write that means a destructuring parameter with default values
>> within the pattern cannot be observed via arguments[i] as undefined (or
>> null?). If missing, the undefined will be replaced by a fresh object. This
>> isn't consistent with any other combination of destructuring parameters and
>> parameter default values.
>>
>> 2. If a function wants to throw an error for a missing options parameter, it
>> has no way of telling other than arguments.length checking.
>
> function f({a,b} = (optionsMissing=true,{})) {
>var optionsMissing;
>if (optionsMissing) throw "missing options parameter";
>...
>
> or using Dave's do operator:
>
> function f({a,b} = do{ throw "missing options parameter",({})}) {
Ok, that's plausible for such a hard case. Let's get to 3, and past it.
>> 3. It's not hard to write " = {}".
>
> I agree. I'm a little uncomfortable with exceptions originating from formal
> parameter initialization, but as soon as we allowed for default value
> expressions that became a possibility. Overall, I suspect that implicitly
> providing a "={}" is just going to mask logic errors.
Also, how deep do you go:
function deep({{{hi = "there"}}}) {...}
deep() // this creates three objects?
The object creation could be optimized away, maybe, but the smell is getting
worse. EIBTI.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
> On Nov 20, 2011, at 1:18 PM, David Herman wrote:
>
>>> I would not add more implicit magic to JS. E4X had junk like this in it,
>>> which only ever concealed bugs.
>>
>> I'm of two minds about this. In the abstract, I agree with Brendan;
>> fail-soft conceals bugs. But in reality, our destructuring logic is
>> incredible fail-soft. Hardly anything in destructuring is treated as an
>> error. And the syntax really *wants* to match the common pattern. So I'm
>> torn.
>
> 1. Failing to write that means a destructuring parameter with default values
> within the pattern cannot be observed via arguments[i] as undefined (or
> null?). If missing, the undefined will be replaced by a fresh object. This
> isn't consistent with any other combination of destructuring parameters and
> parameter default values.
>
> 2. If a function wants to throw an error for a missing options parameter, it
> has no way of telling other than arguments.length checking.
function f({a,b} = (optionsMissing=true,{})) {
var optionsMissing;
if (optionsMissing) throw "missing options parameter";
...
or using Dave's do operator:
function f({a,b} = do{ throw "missing options parameter",({})}) {
>
> 3. It's not hard to write " = {}".
I agree. I'm a little uncomfortable with exceptions originating from formal
parameter initialization, but as soon as we allowed for default value
expressions that became a possibility. Overall, I suspect that implicitly
providing a "={}" is just going to mask logic errors.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 21, 2011, at 8:49 AM, Allen Wirfs-Brock wrote:
> On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
>
>> On Nov 20, 2011, at 1:18 PM, David Herman wrote:
>>
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
>>>
>>> I'm of two minds about this. In the abstract, I agree with Brendan;
>>> fail-soft conceals bugs. But in reality, our destructuring logic is
>>> incredible fail-soft. Hardly anything in destructuring is treated as an
>>> error. And the syntax really *wants* to match the common pattern. So I'm
>>> torn.
>>
>> 1. Failing to write that means a destructuring parameter with default values
>> within the pattern cannot be observed via arguments[i] as undefined (or
>> null?). If missing, the undefined will be replaced by a fresh object. This
>> isn't consistent with any other combination of destructuring parameters and
>> parameter default values.
>
> Actually, I've specified parameter default value initialization such that the
> arguments object is an array of the actual argument values. It contains no
> default value substitutions. Even if function f({a,b}) is interpreted as
> function f({a,b}=undefined) the value of arguments[0] for a call of the form
> f(undefined) would still be undefined.
>
> I'm not particularly in favor of treating undefined/null as { }, but I don't
> think the arguments object is particularly relevant to the issue.
If you had not preserved the actual undefined, I would argue differently. We
all hate arguments but chipping away at consistency involving observations made
using it has a bad smell.
What about points 2 and 3?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
> On Nov 20, 2011, at 1:18 PM, David Herman wrote:
>
>>> I would not add more implicit magic to JS. E4X had junk like this in it,
>>> which only ever concealed bugs.
>>
>> I'm of two minds about this. In the abstract, I agree with Brendan;
>> fail-soft conceals bugs. But in reality, our destructuring logic is
>> incredible fail-soft. Hardly anything in destructuring is treated as an
>> error. And the syntax really *wants* to match the common pattern. So I'm
>> torn.
>
> 1. Failing to write that means a destructuring parameter with default values
> within the pattern cannot be observed via arguments[i] as undefined (or
> null?). If missing, the undefined will be replaced by a fresh object. This
> isn't consistent with any other combination of destructuring parameters and
> parameter default values.
Actually, I've specified parameter default value initialization such that the
arguments object is an array of the actual argument values. It contains no
default value substitutions. Even if function f({a,b}) is interpreted as
function f({a,b}=undefined) the value of arguments[0] for a call of the form
f(undefined) would still be undefined.
I'm not particularly in favor of treating undefined/null as { }, but I don't
think the arguments object is particularly relevant to the issue.
allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 20, 2011, at 1:18 PM, David Herman wrote:
>> I would not add more implicit magic to JS. E4X had junk like this in it,
>> which only ever concealed bugs.
>
> I'm of two minds about this. In the abstract, I agree with Brendan; fail-soft
> conceals bugs. But in reality, our destructuring logic is incredible
> fail-soft. Hardly anything in destructuring is treated as an error. And the
> syntax really *wants* to match the common pattern. So I'm torn.
1. Failing to write that means a destructuring parameter with default values
within the pattern cannot be observed via arguments[i] as undefined (or null?).
If missing, the undefined will be replaced by a fresh object. This isn't
consistent with any other combination of destructuring parameters and parameter
default values.
2. If a function wants to throw an error for a missing options parameter, it
has no way of telling other than arguments.length checking.
3. It's not hard to write " = {}".
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
Thanks for the clarification - this helps.
I think however that the constructors of the Globalization API handle this
correctly in most cases. The specs for the cases where the options object is
not provided (sections /(8|9|10).2.(2|3)/), say the constructors behave as if
they had received a minimal default, but that means they then also use all the
other defaults. Effectively, they do:
// handle missing options
if (!ops) {
ops = { foo: defFoo };
}
// normal processing
if (typeof ops.foo === "undefined") {
foo = defFoo;
}
if (typeof ops.bar === "undefined") {
bar = defBar;
}
if (typeof ops.baz === "undefined") {
baz = defBaz;
}
That's a bit redundant, but generally produces the right results.
Maybe breaking the constructor specifications into three subsections is just
confusing, and I should merge them into one?
There is a real problem, however, in the handling of date format components
(10.2.1, and also the strawman for Date.prototype.toLocale(|Date|Time)String):
The default for these components individually is undefined, meaning that the
formatted string should only have the components that the caller requested.
However, if the caller didn't request any components, then a default set should
be filled in. With the current spec, the default set is only filled in if no
options object is provided at all. If the caller, say, wants to request 24-hour
time, it currently also has to specify the components. That's something I need
to fix.
The Globalization constructors don't modify the caller-provided options, by the
way - I think that's a problem in your code.
Thanks,
Norbert
On Nov 19, 2011, at 22:40 , David Herman wrote:
> On Nov 19, 2011, at 5:50 PM, Brendan Eich wrote:
>
>> On Nov 19, 2011, at 2:20 PM, Rick Waldron wrote:
>>
>>> Q. We don't use option parameter like that in JS (see previous point for
>>> actual example)
>>>
>>> Using an object-as-option parameter is a very common API design pattern in
>>> real-world JavaScript today - why anyone would say otherwise is
>>> confounding.
>>
>> Right. For example, ES5's property descriptor and property descriptor map
>> parameters.
>
> It was me. I didn't say JS doesn't use options objects. I said the G11n
> library was using them wrong. They were doing:
>
> if (!ops) {
> ops = { foo: defFoo, bar: defBar, baz: defBaz };
> }
>
> instead of e.g.:
>
> if (!ops)
> ops = {};
> if (typeof ops.foo === "undefined")
> ops.foo = defFoo;
> if (typeof ops.bar === "undefined")
> ops.bar = defBar;
> if (typeof ops.baz === "undefined")
> ops.baz = defBaz;
>
> IOW, it shouldn't be all or nothing, but rather each property of the options
> object is separately optional.
>
> Dave
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 20, 2011, at 2:24 PM, Brendan Eich wrote:
> On Nov 20, 2011, at 11:16 AM, Allen Wirfs-Brock wrote:
>
>> Actually, I think you would want to say:
>>
>> function frob(arg1, arg2, {foo = defFoo, bar = defBar, baz = defBaz}={}) {
>
> Thanks.
>
>
>> It may be that for destructuring, in general, we want to treat a
>> null/undefined RHS as { }. Eg:
>>
>> let {a=1,b=2,c=3} = undefined;
>> //should this throw or should this be the same as:
>> let {a=1,b=2,c=3} = { };
>
> I would not add more implicit magic to JS. E4X had junk like this in it,
> which only ever concealed bugs.
I'm of two minds about this. In the abstract, I agree with Brendan; fail-soft
conceals bugs. But in reality, our destructuring logic is incredible fail-soft.
Hardly anything in destructuring is treated as an error. And the syntax really
*wants* to match the common pattern. So I'm torn.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 20, 2011, at 11:16 AM, Allen Wirfs-Brock wrote:
> On Nov 20, 2011, at 10:03 AM, Brendan Eich wrote:
>
>> On Nov 20, 2011, at 8:12 AM, Rick Waldron wrote:
>>
>>> Ah, yes and agreed. That was definitely not relayed in the message below-
>>> thanks for the clarification, the context does make a difference.
>>
>> Destructuring parameters + default values really shine here:
>>
>> function frob(arg1, arg2, {foo = defFoo, bar = defBar, baz = defBaz}) {
>> // just use foo, bar, and baz instead of ops.foo, etc.
>> }
>>
>> instead of the song and dance cited below.
>
> Actually, I think you would want to say:
>
> function frob(arg1, arg2, {foo = defFoo, bar = defBar, baz = defBaz}={}) {
Thanks.
> ...
> }
>
> at least, according to how the ES6 draft is currently written.
> Destructurings starts by applying ToObject to the value that is to be
> destructured. ToObject throws for undefined and null. So, destructuring a
> missing argument would throw.
>
> It may be that for destructuring, in general, we want to treat a
> null/undefined RHS as { }. Eg:
>
> let {a=1,b=2,c=3} = undefined;
> //should this throw or should this be the same as:
> let {a=1,b=2,c=3} = { };
I would not add more implicit magic to JS. E4X had junk like this in it, which
only ever concealed bugs.
/be
>
> whichever way we go, we should treat all destructuring binding forms,
> including formal parameters, consistently.
>
> Finally, whether or not you want to directly destructure an options object in
> this matter probably depends upon its treatment of missing options. If a
> missing option means something different from use the default value (such is
> the case of property descriptors) then you wouldn't want to unconditionally
> set missing property values to the default.
>
> Allen
>
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 20, 2011, at 10:03 AM, Brendan Eich wrote:
> On Nov 20, 2011, at 8:12 AM, Rick Waldron wrote:
>
>> Ah, yes and agreed. That was definitely not relayed in the message below-
>> thanks for the clarification, the context does make a difference.
>
> Destructuring parameters + default values really shine here:
>
> function frob(arg1, arg2, {foo = defFoo, bar = defBar, baz = defBaz}) {
> // just use foo, bar, and baz instead of ops.foo, etc.
> }
>
> instead of the song and dance cited below.
Actually, I think you would want to say:
function frob(arg1, arg2, {foo = defFoo, bar = defBar, baz = defBaz}={}) {
...
}
at least, according to how the ES6 draft is currently written. Destructurings
starts by applying ToObject to the value that is to be destructured. ToObject
throws for undefined and null. So, destructuring a missing argument would
throw.
It may be that for destructuring, in general, we want to treat a
null/undefined RHS as { }. Eg:
let {a=1,b=2,c=3} = undefined;
//should this throw or should this be the same as:
let {a=1,b=2,c=3} = { };
whichever way we go, we should treat all destructuring binding forms,
including formal parameters, consistently.
Finally, whether or not you want to directly destructure an options object in
this matter probably depends upon its treatment of missing options. If a
missing option means something different from use the default value (such is
the case of property descriptors) then you wouldn't want to unconditionally set
missing property values to the default.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 20, 2011, at 8:12 AM, Rick Waldron wrote:
> Ah, yes and agreed. That was definitely not relayed in the message below-
> thanks for the clarification, the context does make a difference.
Destructuring parameters + default values really shine here:
function frob(arg1, arg2, {foo = defFoo, bar = defBar, baz = defBaz}) {
// just use foo, bar, and baz instead of ops.foo, etc.
}
instead of the song and dance cited below.
/be
>
> Rick
>
> On Nov 20, 2011, at 1:40 AM, David Herman wrote:
>
>> On Nov 19, 2011, at 5:50 PM, Brendan Eich wrote:
>>
>>> On Nov 19, 2011, at 2:20 PM, Rick Waldron wrote:
>>>
Q. We don't use option parameter like that in JS (see previous point for
actual example)
Using an object-as-option parameter is a very common API design pattern in
real-world JavaScript today - why anyone would say otherwise is
confounding.
>>>
>>> Right. For example, ES5's property descriptor and property descriptor map
>>> parameters.
>>
>> It was me. I didn't say JS doesn't use options objects. I said the G11n
>> library was using them wrong. They were doing:
>>
>> if (!ops) {
>> ops = { foo: defFoo, bar: defBar, baz: defBaz };
>> }
>>
>> instead of e.g.:
>>
>> if (!ops)
>> ops = {};
>> if (typeof ops.foo === "undefined")
>> ops.foo = defFoo;
>> if (typeof ops.bar === "undefined")
>> ops.bar = defBar;
>> if (typeof ops.baz === "undefined")
>> ops.baz = defBaz;
>>
>> IOW, it shouldn't be all or nothing, but rather each property of the options
>> object is separately optional.
>>
>> Dave
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
Ah, yes and agreed. That was definitely not relayed in the message below-
thanks for the clarification, the context does make a difference.
Rick
On Nov 20, 2011, at 1:40 AM, David Herman wrote:
> On Nov 19, 2011, at 5:50 PM, Brendan Eich wrote:
>
>> On Nov 19, 2011, at 2:20 PM, Rick Waldron wrote:
>>
>>> Q. We don't use option parameter like that in JS (see previous point for
>>> actual example)
>>>
>>> Using an object-as-option parameter is a very common API design pattern in
>>> real-world JavaScript today - why anyone would say otherwise is
>>> confounding.
>>
>> Right. For example, ES5's property descriptor and property descriptor map
>> parameters.
>
> It was me. I didn't say JS doesn't use options objects. I said the G11n
> library was using them wrong. They were doing:
>
> if (!ops) {
> ops = { foo: defFoo, bar: defBar, baz: defBaz };
> }
>
> instead of e.g.:
>
> if (!ops)
> ops = {};
> if (typeof ops.foo === "undefined")
> ops.foo = defFoo;
> if (typeof ops.bar === "undefined")
> ops.bar = defBar;
> if (typeof ops.baz === "undefined")
> ops.baz = defBaz;
>
> IOW, it shouldn't be all or nothing, but rather each property of the options
> object is separately optional.
>
> Dave
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 19, 2011, at 5:50 PM, Brendan Eich wrote:
> On Nov 19, 2011, at 2:20 PM, Rick Waldron wrote:
>
>> Q. We don't use option parameter like that in JS (see previous point for
>> actual example)
>>
>> Using an object-as-option parameter is a very common API design pattern in
>> real-world JavaScript today - why anyone would say otherwise is confounding.
>
> Right. For example, ES5's property descriptor and property descriptor map
> parameters.
It was me. I didn't say JS doesn't use options objects. I said the G11n library
was using them wrong. They were doing:
if (!ops) {
ops = { foo: defFoo, bar: defBar, baz: defBaz };
}
instead of e.g.:
if (!ops)
ops = {};
if (typeof ops.foo === "undefined")
ops.foo = defFoo;
if (typeof ops.bar === "undefined")
ops.bar = defBar;
if (typeof ops.baz === "undefined")
ops.baz = defBaz;
IOW, it shouldn't be all or nothing, but rather each property of the options
object is separately optional.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 19, 2011, at 2:20 PM, Rick Waldron wrote: > > Q. We don't use option parameter like that in JS (see previous point for > actual example) > > Using an object-as-option parameter is a very common API design pattern in > real-world JavaScript today - why anyone would say otherwise is confounding. Right. For example, ES5's property descriptor and property descriptor map parameters. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
> > > Q. We don't use option parameter like that in JS (see previous point for > actual example) > Using an object-as-option parameter is a very common API design pattern in real-world JavaScript today - why anyone would say otherwise is confounding. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 18, 2011, at 2:17 PM, Nebojša Ćirić wrote: > I think that we have agreement on being able to set global locale and to move > locale list into options (anybody against?). > > I have couple questions with toLocaleString approach: > > 1. Who imports the @g11n module in this case? Implementation (under which > name) or the user (what happens if they don't, and then try to use > toLocaleString)? Module users name the module, that allows composition in any scope with user-managed names to avoid conflicts. However, we're talking about built-in methods of Number.prototype, Date.protoytpe, etc. -- these can be predefined as if the module were declared by a standard prelude. Would a self-hosted @g11n module monkey-patch these built-in prototypes using ES5 Object.defineProperty? It could, I'm just asking because there are several alternatives: A. We make the new Globalization API part of ECMA-262, or normatively required by referencing a separate standard, so these methods should be observably present from the earliest possible observation point (script or event handler execution). B. We do not make the new G11n API normative/required, so developers will want to object-detect the absence of such prototype methods and polyfill an ES5 self-hosted implementation (large collation table issue TBD). > 2. Do we keep original API (new DateTimeFormat(), and its methods) as an > alternative that would let user: > 2.a. Find out if there were fallbacks through object state That can be done by object-detecting the proto-methods too, right? > 2.b. Apply format repeatedly using the same options (internal caching may > remove this requirement) That seems like it could be a valid use-case in its own right, even with caching. Can you show code written both ways that makes realistic re-use of the object? > 3. Does it make sense to hang Collator on String or any other built-in type? > 4. Would we hang calendars in the future on Date? I don't think so, but we should discuss. It's better to avoid injecting globals, which led ES5 to extend Object and Array a bit with new "static methods". But with a module, top-level functions can be exported from the module, without polluting the global scope. The module client names the module and uses dot to reference the imports, or imports the exports into local names directly referencing the functions. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
I think that we have agreement on being able to set global locale and to
move locale list into options (anybody against?).
I have couple questions with toLocaleString approach:
1. Who imports the @g11n module in this case? Implementation (under which
name) or the user (what happens if they don't, and then try to use
toLocaleString)?
2. Do we keep original API (new DateTimeFormat(), and its methods) as an
alternative that would let user:
2.a. Find out if there were fallbacks through object state
2.b. Apply format repeatedly using the same options (internal caching may
remove this requirement)
3. Does it make sense to hang Collator on String or any other built-in type?
4. Would we hang calendars in the future on Date?
18. новембар 2011. 13.16, Erik Arvidsson је
написао/ла:
> On Fri, Nov 18, 2011 at 12:41, Norbert Lindenberg
> wrote:
> > With that, the first example would become:
> >
> > var price = 300,
> >currency = price.toLocaleString(localeList, {style: "currency",
> currency: "USD"});
>
> We also talked about moving the localeList into the options and
> defaulting to the default localelist which would make it even more
> concise.
>
> var price = 300;
> var currency = price.toLocaleString({style: "currency", currency: "USD"});
>
> --
> erik
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Fri, Nov 18, 2011 at 12:41, Norbert Lindenberg
wrote:
> With that, the first example would become:
>
> var price = 300,
> currency = price.toLocaleString(localeList, {style: "currency", currency:
> "USD"});
We also talked about moving the localeList into the options and
defaulting to the default localelist which would make it even more
concise.
var price = 300;
var currency = price.toLocaleString({style: "currency", currency: "USD"});
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
Thanks for the clarification. Let's see what we can do to reduce object
creation.
At the TC 39 meeting, we seemed to have agreement that it's OK for the
Globalization specification to respecify the existing *Locale* methods, as
proposed here:
http://wiki.ecmascript.org/doku.php?id=strawman:globalization-integration
With that, the first example would become:
var price = 300,
currency = price.toLocaleString(localeList, {style: "currency", currency:
"USD"});
NumberFormat supports three styles, with "decimal" being the default, so we
could reduce the need for options objects by adding functions
toLocaleCurrencyString and toLocalePercentString, specified (but not
implemented) as:
Number.prototype.toLocaleCurrencyString = function(localeList, currency,
options) {
var myOptions = Object.create(options, {style: "currency", currency:
currency});
return (new Globalization.NumberFormat(localeList, myOptions)).format(this);
}
This would let you use:
var currency = price.toLocaleCurrencyString(localeList, "USD");
Is that a good trade-off, introducing new functions for common use cases in
order to avoid object creation? Note that if you format lots of currency
strings, you're probably better off performance-wise to openly create the
NumberFormat object and reuse it, rather than having the implementation look
for it in its cache based on your parameters each time around.
The second example would be:
var now = new Date(),
pretty = now.toLocaleDateString(localeList);
assuming that you can live with the locale's default representation for day and
month (some will pad to two digits, others won't). If you do need padding to
two digits, it would currently be:
var pretty = now.toLocaleDateString(localeList, {year: "numeric", month:
"2-digit", day: "2-digit"});
So much on the current situation - I'm looking forward to your feedback!
Thanks,
Norbert
On Nov 18, 2011, at 11:26 , Nicholas Zakas wrote:
> As part of the group that said the API is too Java-like, I'd like to
> clarify. "Java-like" to me means that you need to create one or more
> objects that are only kept around for a short period of time to
> perform a single task. For example, if I already have a Number object
> and want to format that number as currency, I'd expect to be able to
> do something like this:
>
> var price = 300,
>currency = price.toCurrencyString("USD");
>
> Likewise for formatting dates:
>
> var now = new Date(),
>pretty = now.toFormatString("mm/dd/");
>
> Or some such thing. Realizing, of course, the discussion around
> wanting to avoid formatting strings.
>
> I'll be writing up a longer piece of feedback this weekend.
>
> -N
>
>
>
> On Thu, Nov 17, 2011 at 5:29 PM, Brendan Eich wrote:
>> On Nov 17, 2011, at 2:22 PM, Nebojša Ćirić wrote:
>>>
>>> Q. API is too Java like. Use shorthand to invoke formatters.
>>> A. I would like to hear proposals on how to make it more JS like. Adding
>>> shorthand syntax is easy, but most of TC39 members were against having 2
>>> ways of doing things first time we proposed it.
>>> Here is an example of current API in action - http://pastebin.com/pjfdKYss
>>
>> Would converting constructors into factories help make API less Java like?
>> For example, instead of:
>> var dtf = new DateTimeFormat(...);
>> we have
>> var dtf = createDateTimeFormat(...);
>>
>> No, that's worse. Constructors used with 'new' are ok if you really need a
>> new object to do something.
>> What's JS-esque is to use a *function* when you don't need to allocate an
>> object just to call one method on it, then let it become garbage to collect.
>> Also being able to use the function as a first-class value (pass it around
>> as a funarg, stick it on some other object, decorate it with ad-hoc
>> properties).
>> /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
As part of the group that said the API is too Java-like, I'd like to
clarify. "Java-like" to me means that you need to create one or more
objects that are only kept around for a short period of time to
perform a single task. For example, if I already have a Number object
and want to format that number as currency, I'd expect to be able to
do something like this:
var price = 300,
currency = price.toCurrencyString("USD");
Likewise for formatting dates:
var now = new Date(),
pretty = now.toFormatString("mm/dd/");
Or some such thing. Realizing, of course, the discussion around
wanting to avoid formatting strings.
I'll be writing up a longer piece of feedback this weekend.
-N
On Thu, Nov 17, 2011 at 5:29 PM, Brendan Eich wrote:
> On Nov 17, 2011, at 2:22 PM, Nebojša Ćirić wrote:
>>
>> Q. API is too Java like. Use shorthand to invoke formatters.
>> A. I would like to hear proposals on how to make it more JS like. Adding
>> shorthand syntax is easy, but most of TC39 members were against having 2
>> ways of doing things first time we proposed it.
>> Here is an example of current API in action - http://pastebin.com/pjfdKYss
>
> Would converting constructors into factories help make API less Java like?
> For example, instead of:
> var dtf = new DateTimeFormat(...);
> we have
> var dtf = createDateTimeFormat(...);
>
> No, that's worse. Constructors used with 'new' are ok if you really need a
> new object to do something.
> What's JS-esque is to use a *function* when you don't need to allocate an
> object just to call one method on it, then let it become garbage to collect.
> Also being able to use the function as a first-class value (pass it around
> as a funarg, stick it on some other object, decorate it with ad-hoc
> properties).
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Nicholas C. Zakas
http://www.nczonline.net
@slicknet
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
On Nov 17, 2011, at 2:22 PM, Nebojša Ćirić wrote: > Q. API is too Java like. Use shorthand to invoke formatters. > A. I would like to hear proposals on how to make it more JS like. Adding > shorthand syntax is easy, but most of TC39 members were against having 2 ways > of doing things first time we proposed it. > Here is an example of current API in action - http://pastebin.com/pjfdKYss > > > Would converting constructors into factories help make API less Java like? > > For example, instead of: > > var dtf = new DateTimeFormat(...); > > we have > > var dtf = createDateTimeFormat(...); No, that's worse. Constructors used with 'new' are ok if you really need a new object to do something. What's JS-esque is to use a *function* when you don't need to allocate an object just to call one method on it, then let it become garbage to collect. Also being able to use the function as a first-class value (pass it around as a funarg, stick it on some other object, decorate it with ad-hoc properties). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
> > Q. API is too Java like. Use shorthand to invoke formatters. > A. I would like to hear proposals on how to make it more JS like. Adding > shorthand syntax is easy, but most of TC39 members were against having 2 > ways of doing things first time we proposed it. > Here is an example of current API in action - http://pastebin.com/pjfdKYss > > Would converting constructors into factories help make API less Java like? For example, instead of: var dtf = new DateTimeFormat(...); we have var dtf = createDateTimeFormat(...); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API discussion
Pastebin may be better for showing syntax - http://pastebin.com/pjfdKYss. 17. новембар 2011. 10.33, Nebojša Ćirić је написао/ла: > Hi all, > there were couple concerns yesterday about the API (some concrete, some > vague), and we would like to resolve those as soon as possible. Here is the > list of issues I got yesterday (I am sure there's more we didn't manage to > cover): > > Q. We need a way to set default locale (per context). Currently one can > only read its value by constructing LocaleList without parameters. > A. A global defaultLocale (attached to Globalization namespace) was > proposed. I agree with the idea. > > Q. Move LocaleList parameter in all constructors to options parameter. > A. This would help avoid putting "undefined" as first parameter if we are > happy with the defaults. > > Q. API is too Java like. Use shorthand to invoke formatters. > A. I would like to hear proposals on how to make it more JS like. Adding > shorthand syntax is easy, but most of TC39 members were against having 2 > ways of doing things first time we proposed it. > Here is an example of current API in action - > http://codepaste.appspot.com/show?id=592122&revid=589126 > > Q. We don't use option parameter like that in JS (see previous point for > actual example) > A. What is a proper way of passing variable list of parameters that lets > you extend the list in the future in an easy way? All of the properites in > the options object are optional (with some exceptions) > > Feel free to start a new email thread for hot topics. > > -- > Nebojša Ćirić > -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Globalization API discussion
Hi all, there were couple concerns yesterday about the API (some concrete, some vague), and we would like to resolve those as soon as possible. Here is the list of issues I got yesterday (I am sure there's more we didn't manage to cover): Q. We need a way to set default locale (per context). Currently one can only read its value by constructing LocaleList without parameters. A. A global defaultLocale (attached to Globalization namespace) was proposed. I agree with the idea. Q. Move LocaleList parameter in all constructors to options parameter. A. This would help avoid putting "undefined" as first parameter if we are happy with the defaults. Q. API is too Java like. Use shorthand to invoke formatters. A. I would like to hear proposals on how to make it more JS like. Adding shorthand syntax is easy, but most of TC39 members were against having 2 ways of doing things first time we proposed it. Here is an example of current API in action - http://codepaste.appspot.com/show?id=592122&revid=589126 Q. We don't use option parameter like that in JS (see previous point for actual example) A. What is a proper way of passing variable list of parameters that lets you extend the list in the future in an easy way? All of the properites in the options object are optional (with some exceptions) Feel free to start a new email thread for hot topics. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
