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
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.
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
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.
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 dher...@mozilla.com wrote:
On Nov 19, 2011, at 5:50 PM, Brendan Eich wrote:
On Nov 19, 2011, at 2:20
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,
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
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
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
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
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
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
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
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
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:
On Fri, Nov 18, 2011 at 12:41, Norbert Lindenberg
ecmascr...@norbertlindenberg.com 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
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
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
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).
Pastebin may be better for showing syntax - http://pastebin.com/pjfdKYss.
17. новембар 2011. 10.33, Nebojša Ćirić c...@google.com је написао/ла:
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.
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
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
22 matches
Mail list logo
