Le 16 janv. 2013 à 09:11, David Bruant bruan...@gmail.com a écrit :
Hi,
This is an idea naturally derived of all the current discussions about
WeakMaps and Private symbols. The proposal is easily summarized by these
lines of code:
var wm = new WeakMap();
var o = {};
o[wm] =
Le 21/01/2013 10:05, Claude Pache a écrit :
Le 16 janv. 2013 à 09:11, David Bruant bruan...@gmail.com a écrit :
Hi,
This is an idea naturally derived of all the current discussions about WeakMaps
and Private symbols. The proposal is easily summarized by these lines of code:
var wm = new
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 considered as abusive ambient
authority.
Let's see how this feature came
Le 21 janv. 2013 à 11:58, David Bruant bruan...@gmail.com a écrit :
Le 21/01/2013 10:05, Claude Pache a écrit :
Le 16 janv. 2013 à 09:11, David Bruant bruan...@gmail.com a écrit :
Hi,
This is an idea naturally derived of all the current discussions about
WeakMaps and Private symbols.
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
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
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 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
On 17 January 2013 21:08, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
Actually, I don't see why this should have a measurable impact on
performance in practice. The generic case is dog-slow for JavaScript
anyway, what matters is how easy it is to specialise for the types
Brendan Eich wrote:
David Bruant wrote:
Hi,
This is an idea naturally derived of all the current discussions about
WeakMaps and Private symbols. The proposal is easily summarized by
these lines of code:
var wm = new WeakMap();
var o = {};
o[wm] = 12 // desugars to wm.set(o, 12)
var a =
Andreas Rossberg wrote:
Actually, I don't see why this should have a measurable impact on
performance in practice. The generic case is dog-slow for JavaScript
anyway, what matters is how easy it is to specialise for the types
actually seen at runtime. And there, this would just add yet another
On Jan 16, 2013, at 10:53 AM, David Bruant wrote:
Le 16/01/2013 19:42, Brendan Eich a écrit :
David Bruant wrote:
Hi,
This is an idea naturally derived of all the current discussions about
WeakMaps and Private symbols. The proposal is easily summarized by these
lines of code:
var
Allen Wirfs-Brock wrote:
If you want to explore this area, I suggest taking a fresh look at
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
How does that help? It does not transpose terms of [] and delegate to
the left (formerly right) operand.
/be
Le 16/01/2013 20:27, Brendan Eich a écrit :
David Bruant wrote:
Le 16/01/2013 19:42, Brendan Eich a écrit :
David Bruant wrote:
Hi,
This is an idea naturally derived of all the current discussions
about WeakMaps and Private symbols. The proposal is easily
summarized by these lines of code:
David Bruant wrote:
Am I misunderstanding how JIT compilation using type information works?
The problem is not just adding another deoptimization path. Not all JITs
use only PICs. Lots of optimizations are possible. But adding a ?: to
the *generic* (I meant what I wrote there) path is not
Le 16/01/2013 21:19, Brendan Eich a écrit :
David Bruant wrote:
Am I misunderstanding how JIT compilation using type information works?
The problem is not just adding another deoptimization path. Not all
JITs use only PICs. Lots of optimizations are possible. But adding a
?: to the
On Jan 16, 2013, at 11:28 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
If you want to explore this area, I suggest taking a fresh look at
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
How does that help? It does not transpose terms of [] and delegate to the
David Bruant wrote:
Le 16/01/2013 21:19, Brendan Eich a écrit :
David Bruant wrote:
Am I misunderstanding how JIT compilation using type information works?
The problem is not just adding another deoptimization path. Not all
JITs use only PICs. Lots of optimizations are possible. But adding
23 matches
Mail list logo
