The November 7, 211 (also known as Rev 4) draft is available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
Let me know if you really need to docx format copy and I'll send it two you. I
haven't found a way to get docuwiki to allow me to upload docx files. It seems
to
Hi Tom,
Thanks for all this work!
Le 07/11/2011 16:54, Tom Van Cutsem a écrit :
> Hi,
>
> I wrote up an initial (but fairly complete) draft of a proposed
> refactoring of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms
> to change the way in which these algorithms climb the prototype
> ch
On Nov 7, 2011, at 10:03 AM, Allen Wirfs-Brock wrote:
> True, "in" and "instanceof" don't follow the rules. I note that they were
> added in ES3 and I have to wonder if they aren't another case of features
> being added without sufficient thought being given to maintaining consistency
> of beh
On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote:
> On 5 November 2011 19:55, Brendan Eich wrote:
>> On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote:
>>
>>> In a similar vain, what is the value of r in:
>>>
>>> let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
>>>
>>> should it be [2
On Nov 7, 2011, at 2:18 AM, Andreas Rossberg wrote:
> On 5 November 2011 17:44, Brendan Eich wrote:
>> Destructuring is "irrefutable" in that it desugars to assignments from
>> properties of the RHS. It is not typed; it is not refutable
>
> I don't think that's true, at least not in the usual s
On Nov 7, 2011, at 12:59 AM, Lasse Reichstein wrote:
> If the object being destructured is in fact a plain Array, with no
> inherited elements above the length, then there is no difference.
> This is most likely the (very) common use case. This is what the ES
> programmers' intuition will be based
We use Google Postini in concert with Mailman. Postini needs to be told
sometimes. If you don't see mail get through, mail es-discuss-ow...@mozilla.org
about it.
/be
On Nov 7, 2011, at 12:48 PM, David Bruant wrote:
> Le 06/11/2011 15:37, Axel Rauschmayer a écrit :
>>
>> Claus Reinke could not
>> Claus Reinke could not submit his js-tools discussion group announcement
>> (interestingly, I could do it for him). And the email I appended underneath
>> my signature never got through. Can someone explain the blocking criteria?
> I have experienced similar problems at some point. I don't kno
On 11/7/11 2:48 PM, David Bruant wrote:
Le 06/11/2011 15:37, Axel Rauschmayer a écrit :
Claus Reinke could not submit his js-tools discussion group
announcement (interestingly, I could do it for him). And the email I
appended underneath my signature never got through. Can someone
explain the blo
Le 06/11/2011 15:37, Axel Rauschmayer a écrit :
> Claus Reinke could not submit his js-tools discussion group
> announcement (interestingly, I could do it for him). And the email I
> appended underneath my signature never got through. Can someone
> explain the blocking criteria?
I have experienced
On Nov 7, 2011, at 9:21 AM, Andreas Rossberg wrote:
> On 7 November 2011 17:34, Allen Wirfs-Brock wrote:
>>> It is just another way to
>>> silently inject an `undefined' that is tedious to track down. We
>>> already have too many of those...
>>
>> It is how the language currently behaves in a
On Nov 7, 2011, at 9:32 AM, Axel Rauschmayer wrote:
> How about:
>
> let {length} = "abc";
or
let [first,second] = "abc";
>
> I think the conversion keeps the illusion alive that every value in JS is an
> object.
>
> On Nov 7, 2011, at 18:21 , Andreas Rossberg wrote:
>
>> On 7 November
How about:
let {length} = "abc";
I think the conversion keeps the illusion alive that every value in JS is an
object.
On Nov 7, 2011, at 18:21 , Andreas Rossberg wrote:
> On 7 November 2011 17:34, Allen Wirfs-Brock wrote:
>>> It is just another way to
>>> silently inject an `undefined' that
On 7 November 2011 17:34, Allen Wirfs-Brock wrote:
>> It is just another way to
>> silently inject an `undefined' that is tedious to track down. We
>> already have too many of those...
>
> It is how the language currently behaves in all situations where an object is
> needed but a primitive val
On Nov 7, 2011, at 3:50 AM, Till Schneidereit wrote:
>> I.e., I think the most easily comprehensible behavior is to make array
>> destructuring treat the RHS as an Array.
>> It matches the common use-case (actual arrays), it is consistent (does
>> the same whether you use ... or not), and is easi
On Nov 6, 2011, at 9:13 PM, Brendan Eich wrote:
> On Nov 6, 2011, at 11:18 AM, Allen Wirfs-Brock wrote:
>
>> On Nov 6, 2011, at 3:53 AM, Till Schneidereit wrote:
...
>>>
>>> After thinking about this some more, I think I'd be fine with the
>>> above outcome after all. It seems to me as tho
On Nov 7, 2011, at 8:23 AM, Andreas Rossberg wrote:
> On 7 November 2011 17:07, Allen Wirfs-Brock wrote:
>>> let {x} = 666
>>>
>>> which will be refuted, by raising a TypeError.
>>
>> No,
>>
>> It does ToObject(666) and then looks for the "x" property of the resulting
>> wrapper object.
>
On 7 November 2011 17:07, Allen Wirfs-Brock wrote:
>> let {x} = 666
>>
>> which will be refuted, by raising a TypeError.
>
> No,
>
> It does ToObject(666) and then looks for the "x" property of the resulting
> wrapper object.
Ouch, really? I don't see that in the proposal
(http://wiki.ecmascri
On Nov 7, 2011, at 2:18 AM, Andreas Rossberg wrote:
> On 5 November 2011 17:44, Brendan Eich wrote:
>> Destructuring is "irrefutable" in that it desugars to assignments from
>> properties of the RHS. It is not typed; it is not refutable
>
> I don't think that's true, at least not in the usual
Hi,
I wrote up an initial (but fairly complete) draft of a proposed refactoring
of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the
way in which these algorithms climb the prototype chain: <
http://wiki.ecmascript.org/doku.php?id=strawman:refactoring_put>
This is mainly benef
> I.e., I think the most easily comprehensible behavior is to make array
> destructuring treat the RHS as an Array.
> It matches the common use-case (actual arrays), it is consistent (does
> the same whether you use ... or not), and is easily explainable.
I agree with the consistency argument. The
On 5 November 2011 19:55, Brendan Eich wrote:
> On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote:
>
>> In a similar vain, what is the value of r in:
>>
>> let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
>>
>> should it be [2] or [2,3,4] (and if the latter how is that determined)?
>
> The
On 5 November 2011 17:44, Brendan Eich wrote:
> Destructuring is "irrefutable" in that it desugars to assignments from
> properties of the RHS. It is not typed; it is not refutable
I don't think that's true, at least not in the usual sense of
"irrefutable pattern". Because you can write
let {
On Sat, Nov 5, 2011 at 10:41 PM, Brendan Eich wrote:
> We have:
>
> 1. Should an array pattern always query 'length'?
>
> 2. If the answer to (1) is "no", then should ... in an array pattern query
> 'length'?
>
> On reflection and at this point in the thread, with your reply in mind, my
> prefs
24 matches
Mail list logo
