Le 22 janv. 2013 à 22:34, David Bruant bruan...@gmail.com a écrit :
Back to weakmaps, the issue here is not technical, but... cultural I would
say.
Indeed, the issue is cultural. We are questioning WeakMap.prototype.clear,
because some people think that WeakMap should provide some strong
just imagine I gave up with polyfills and shim creating my own thing that
work ... called HybridMap ...
Seriously, private symbols are ES7 stuff while WeakMaps are already in ES6,
right? So go for whatever weak definition it is rather than delay partial
improvements for other 4 years, IMHO!
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true before
its adoption (you can only modify a weakmap entry if you have the key)
David, would you please elaborate your argument for this invariant? This
the
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true
before its adoption (you can only modify a weakmap entry if you
have
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant bruan...@gmail.com wrote:
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true before
its adoption (you can
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant bruan...@gmail.com wrote:
However, Mark showed an elegant way to implement .clear on top of
clear-less weakmaps and the class syntax [4][5] (reproducing here the final
version for clarity)
Sure—and roughly the same code can be used to *remove* an
Le 22/01/2013 15:19, Jason Orendorff a écrit :
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
On Tue, Jan 22, 2013 at 2:47 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true before
its adoption (you can only modify a weakmap entry if you have the
On Tue, Jan 22, 2013 at 9:01 AM, David Bruant bruan...@gmail.com wrote:
class WeakMapWithoutClear {
Yep. Glad to see we are thinking along the same lines.
What this and my previous show is an semantics equivalence between
clearable and clear-less weakmaps. Which should be chosen as
On Jan 22, 2013, at 7:18 AM, Mark S. Miller wrote:
But WeakMaps were introduced specifically to support rights
amplification[1].
Perhaps, from your perspective, but not from mine. The above is certainly not
a phrase I would ever say, I'm not even sure of your exact technical definition
Le 21/01/2013 22:42, Allen Wirfs-Brock a écrit :
On Jan 21, 2013, at 12:25 PM, David Bruant wrote:
Le 21/01/2013 20:52, Allen Wirfs-Brock a écrit :
On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
This is the reality check I can get behind—I'm hard pressed to come up with a
use case that
Le 22/01/2013 15:59, Jason Orendorff a écrit :
A) Are there more WeakMap applications that will want .clear() or
applications that will want .clear() not to exist? Offhand I would bet
on the former, by a landslide, but if you think otherwise, or if
there's some other reason to privilege
I would like to humbly say that if this `WeakMap#clear()` method is anyhow
slowing down or reminding the adoption of the WeakMap concept itself for
all browsers, just mark it TBD and go on with the rest: WeakMap is needed
and wanted since ever, `clear()` gotchas can be discussed for all the time
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
Le 21/01/2013 17:16, Rick Waldron a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
mailto: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
If you don't want to expose clear on a WeakMap, create a subclass that doesn't
support it:
class WeakMapWithoutClear extends WeakMap {
delete() {throw Error(Clearing this map is not allowed);
}
if you are really paranoid that somebody is going to do
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
Le 21/01/2013 18:02, Allen Wirfs-Brock a écrit :
If you don't want to expose clear on a WeakMap, create a subclass that doesn't
support it:
class WeakMapWithoutClear extends WeakMap {
delete() {throw Error(Clearing this map is not allowed);
}
if you are really paranoid that somebody is
Le 21/01/2013 18:38, Andrea Giammarchi a écrit :
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.
+1
Said that, even localStorage lets us remove all keys even if it wasn't
On Jan 21, 2013, at 9:38 AM, Andrea Giammarchi 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
No markup version of the latest ES6 spec (pdf link)
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_draftscache=cachemedia=harmony:working_draft_ecma-262_edition_6_12-21-12-nomarkup.pdf
Rick
On Mon, Jan 21, 2013 at 12:38 PM, Andrea Giammarchi
Sorry for the echo
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mon, Jan 21, 2013 at 3:04 AM, David Bruant bruan...@gmail.com wrote:
Le 21/01/2013 11:58, David Bruant a écrit :
Before the clear method, weakmaps had the following property: you can
only modify a weakmap entry if you have the key. This property isn't true
anymore with .clear. This may be
On Jan 21, 2013, at 10:20 AM, Mark S. Miller wrote:
Hi David, thanks for raising this. Not having been able to take much
time lately, I had not been aware that a .clear method had been added.
I think it's a terrible idea. I like your explanation of why --
because of the simple property it
On Mon, Jan 21, 2013 at 11:44 AM, David Bruant bruan...@gmail.com wrote:
Le 21/01/2013 17:16, Rick Waldron a écrit :
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 Jan 21, 2013, at 10:46 AM, Mark S. Miller wrote:
On Mon, Jan 21, 2013 at 10:40 AM, Mark S. Miller erig...@google.com wrote:
On Mon, Jan 21, 2013 at 9:02 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If you don't want to expose clear on a WeakMap, create a subclass that
doesn't
Le 21/01/2013 20:30, Brendan Eich a écrit :
David Bruant wrote:
I guess TC39 agrees on the Any new method added to one is going to
get added to all of them, unless
Why do you guess that?
I didn't see anything in the notes about discussions related
specifically to WeakMap.prototype.clear,
On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
This is the reality check I can get behind—I'm hard pressed to come up with a
use case that isn't contrived or solvable by some other means.
This is easy:
I'm do phased traversals over a complex data structure. I have a number of
On Mon, Jan 21, 2013 at 2:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
This is the reality check I can get behind—I'm hard pressed to come up
with a use case that isn't contrived or solvable by some other means.
This is easy:
On Jan 21, 2013, at 12:25 PM, David Bruant wrote:
Le 21/01/2013 20:52, Allen Wirfs-Brock a écrit :
On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
This is the reality check I can get behind—I'm hard pressed to come up with
a use case that isn't contrived or solvable by some other means.
On Jan 21, 2013, at 1:55 PM, Mark S. Miller wrote:
...
That's why it's important that common patterns, such as the rights
amplification pattern, which don't actually need the costs of
ephemeron gc, shouldn't have to pay these costs because of the
presence of a clear method they don't use.
31 matches
Mail list logo
