No markup version of the latest ES6 spec (pdf link)
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_12-21-12-nomarkup.pdf
Rick
On Mon, Jan 21, 2013 at 12:38 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> somebody asked why clear() is needed, when if you have the reference you
> can simply ref = new WeakMap; instead of clearing, while clear() exposes
> undesired side effects.
> Said that, even localStorage lets us remove all keys even if it wasn't us
> setting them so ... well, I guess we can survive then with clear().
>
> This is specially for Rick, since it's holidays today and I am bored home
> :D
> Where is exactly the latest state of es6 collections? I have no idea how I
> should update mine accordingly, please point me to the very latest, most
> updated, agreed link 'cause I am confused.
>
> Thanks and have a nice day or evening
>
>
> On Mon, Jan 21, 2013 at 8:16 AM, Rick Waldron <waldron.r...@gmail.com>wrote:
>
>> On Mon, Jan 21, 2013 at 6:04 AM, David Bruant <bruan...@gmail.com> wrote:
>>
>>> I think WeakMap.prototype.clear slipped through the crack without being
>>> specifically discussed. Based on what's publicly available, I don't see
>>> anyone noticed and discussed the fact that WeakMap.prototype.clear
>>> questions the property that was true before its adoption ("you can only
>>> modify a weakmap entry if you have the key")
>>>
>>
>> I agree and disagree. I disagree because WeakMap.prototype.clear()
>> doesn't modify the weakmap entry in the same direct way, ie.
>> WeakMap.prototype.set, WeakMap.prototype.delete. On the other hand, I agree
>> because it provides (if the weakmap is exposed) a way to remove an entry
>> that might be used without any defense, ie. WeakMap.prototype.has() or
>> might leave the program in an unstable state due to loss of some aggregate
>> state information stored in the weakmap.
>>
>> That being said, I support the inclusion of WeakMap.prototype.clear(),
>> because reasonable security and state defense expectations can be met by:
>>
>> 1. Not exposing a sensitive weakmap in program code
>> 2. Defending against missing entries with has()
>>
>> Subjectively, #1 mitigates without nannying.
>>
>> Rick
>>
>>
>>
>>>
>>> I think the property I mentioned is cricial to weakmap integrity and I
>>> think WeakMap.prototype.clear should be considered for removal... or at
>>> least proper discussion since none really happened from what I've found.
>>>
>>> David
>>>
>>> [1] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
>>> October/025962.html<https://mail.mozilla.org/pipermail/es-discuss/2012-October/025962.html>
>>> [2] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
>>> November/026114.html<https://mail.mozilla.org/pipermail/es-discuss/2012-November/026114.html>
>>> [3]
>>> https://github.com/rwldrn/**tc39-notes<https://github.com/rwldrn/tc39-notes>
>>> [4] https://github.com/rwldrn/**tc39-notes/blob/master/es6/**
>>> 2012-11/nov-27.md#review-of-**new-draft-spec<https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-27.md#review-of-new-draft-spec>
>>> [5] http://wiki.ecmascript.org/**doku.php?id=harmony:**
>>> specification_drafts<http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts>
>>> [6]
>>> https://bugzilla.mozilla.org/**show_bug.cgi?id=814562<https://bugzilla.mozilla.org/show_bug.cgi?id=814562>
>>> ______________________________**_________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
