On 11/17/2011 10:03 PM, Dominic Cooney wrote:
On Fri, Nov 18, 2011 at 9:40 AM, Waldemar Horwat mailto:walde...@google.com>> wrote:
Array destructuring and length:
let [a, b, c, d, ... r] = {2: 3} <| [1, 2]
Obvious: a is 1; b is 2.
What are c, d, and r?
c = 2.
Nit: This sh
>
> snip
> Quick reply to suggest that rest is the wrong proposal. You want
>
> http://wiki.ecmascript.org/doku.php?id=harmony:spread
>
> http://wiki.ecmascript.org/doku.php?id=harmony:spread#11.1.4_array_initialiser
>
Thanks! That's a much better resource - and the [...arrayish] example
_does_ ma
On Nov 18, 2011, at 8:54 AM, Rick Waldron wrote:
> On Thu, Nov 17, 2011 at 11:06 PM, David Herman wrote:
> On Nov 17, 2011, at 5:20 PM, Rick Waldron wrote:
>
>> On Thu, Nov 17, 2011 at 7:40 PM, Waldemar Horwat wrote:
>> Array.from(a) is superfluous because it's expressed even simpler as
>> [...
On Nov 18, 2011, at 7:15 AM, David Bruant wrote:
> Subarray having a 'from' method sounds like a good idea, but it
> inheriting it from Array sounds counter-intuitive, because Array is
> indeed more of a placeholder than anything else. Very much like
> Object.getOwnPropertyDescriptor.
It depends.
On Thu, Nov 17, 2011 at 11:06 PM, David Herman wrote:
> On Nov 17, 2011, at 5:20 PM, Rick Waldron wrote:
>
> On Thu, Nov 17, 2011 at 7:40 PM, Waldemar Horwat wrote:
>
>> Array.from(a) is superfluous because it's expressed even simpler as
>> [... a]. DaveH withdrew it.
>>
>
> Perhaps Array.from()
On Nov 17, 2011, at 5:20 PM, Rick Waldron wrote:
> This is a real problem, in real JavaScript, in the real world. Considering
> the positive response from actual developers in the JS community, I'd like to
> ask that it be reconsidered.
You can write this function in JS today:
function arr
Le 18/11/2011 01:40, Waldemar Horwat a écrit :
> Array.from discussion: What happens if you subclass Array?
> Subarray = Array <| function() {...}
> Subarray.from(arraylike)
Subarray having a 'from' method sounds like a good idea, but it
inheriting it from Array sounds counter-intuitive, because A
On Fri, Nov 18, 2011 at 9:40 AM, Waldemar Horwat wrote:
> Array destructuring and length:
> let [a, b, c, d, ... r] = {2: 3} <| [1, 2]
> Obvious: a is 1; b is 2.
> What are c, d, and r?
> c = 2.
>
Nit: This should be c = 3, because {2: 3} means ({2: x} <| [1, 2])[2] is x,
right?
> d = undefined
On Nov 17, 2011, at 5:20 PM, Rick Waldron wrote:
> On Thu, Nov 17, 2011 at 7:40 PM, Waldemar Horwat wrote:
> Array.from(a) is superfluous because it's expressed even simpler as
> [... a]. DaveH withdrew it.
>
> Perhaps Array.from() was either misunderstood or miscommunicated. I had
> prepared
On Nov 17, 2011, at 4:40 PM, Waldemar Horwat wrote:
> Tom: Use a null target to indicate a permanently "virtual" object.
> Brendan: Proxy.DonJuan
He refuses to commit.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/list
On Thu, Nov 17, 2011 at 7:40 PM, Waldemar Horwat wrote:
> Array destructuring and length:
> let [a, b, c, d, ... r] = {2: 3} <| [1, 2]
> Obvious: a is 1; b is 2.
> What are c, d, and r?
> c = 2.
> d = undefined.
> r = empty.
>
> Fixed property destructuring doesn't rely on length.
> Vararg r destr
Array destructuring and length:
let [a, b, c, d, ... r] = {2: 3} <| [1, 2]
Obvious: a is 1; b is 2.
What are c, d, and r?
c = 2.
d = undefined.
r = empty.
Fixed property destructuring doesn't rely on length.
Vararg r destructuring uses length.
The semantics of length will match that of slice.
All
Here are my meeting notes for today.
Waldemar
WebIDL: Can abstract interfaces have static members? Don't see why
not -- they'd just be spec sugar for adding the same static member to
concrete classes that derive from those abstract interfaces. As
usual, it would be a spec error to have a c
13 matches
Mail list logo
