On 2 December 2014 at 19:15, Mark S. Miller erig...@google.com wrote:
In both minor or major collection both m and v are immediately
reclaimed, because neither is strongly reachable at that point
which shows the asymmetry, and that v8 is effectively optimizing for
the wrong side of that
On Wed, Dec 3, 2014 at 8:35 AM, Andreas Rossberg rossb...@google.com wrote:
(Back to the actual topic of this thread, you still owe me a reply
regarding why .clear is bad for security. ;) )
I'd like to hear this too, just for education value.
-j
___
Le 03/12/2014 16:26, Jason Orendorff a écrit :
On Wed, Dec 3, 2014 at 8:35 AM, Andreas Rossberg rossb...@google.com wrote:
(Back to the actual topic of this thread, you still owe me a reply
regarding why .clear is bad for security. ;) )
I'd like to hear this too, just for education value.
It seems the typical way to do this is:
Object.keys(myObj).forEach(key = {
let value = myObj[key];
// Do something with value and/or key.
});
I don't see a new way to do this in ES6.
Is it still being considered to add the methods entries and values to
Object that return iterators?
--
R.
The same argument can be used for removing array.length setter - some code
can remove all entries from array important for your application.
Maybe we should think about WM methods .clone and cloneInto(otherWeakMap).
3 gru 2014 18:04 David Bruant bruan...@gmail.com napisał(a):
Le 03/12/2014
On Wed, Dec 3, 2014 at 9:10 AM, Michał Wadas michalwa...@gmail.com wrote:
The same argument can be used for removing array.length setter - some code
can remove all entries from array important for your application.
No it's not, because Arrays are open to editing in all ways. They
don't have
On Thu, Nov 27, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
This is the end of my assumed inverted WC design and why I assert that a
clear method is incompatible with it.
Couldn't this be solved by adding a little state (a monotonically
increasing 'generation' counter)
It seems a bit late to add a default @@iterator to Object.prototype, but I
guess it could work similar to Map.prototype.entries, if such a thing were to
be added.
Have to be really careful adding things to Object.prototype, though — even when
they’re non-enumerable, they can cause unexpected
Have to be really careful adding things to Object.prototype, though — even
when they’re non-enumerable, they can cause unexpected problems in code (code
which probably ought to be using Object.create(null), but you know, doesn’t).
Being a Symbol rather than a String property key probably
On Wed, Dec 3, 2014 at 9:04 AM, David Bruant bruan...@gmail.com wrote:
A script which builds a weakmap may legitimately later assume the weakmap is
filled. However, passing the weakmap to a mixed-trusted (malicious or buggy)
script may result in the weakmap being cleared (and break the
On Wed, Dec 3, 2014 at 1:10 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Wed, Dec 3, 2014 at 9:04 AM, David Bruant bruan...@gmail.com wrote:
A script which builds a weakmap may legitimately later assume the
weakmap is
filled. However, passing the weakmap to a mixed-trusted
for (key of Reflect.ownKeys(myObj)) {
//Do something with key or myObj[key]
}
Allen
On Dec 3, 2014, at 9:07 AM, Mark Volkmann wrote:
It seems the typical way to do this is:
Object.keys(myObj).forEach(key = {
let value = myObj[key];
// Do something with value and/or key.
});
I
A more compact implementation occurred to me during my commute: just have
an internal slot in the WC that it uses when looking up values, instead of
the WC reference itself.
This has the downside of not being able to purge old slots on calls to
has/get, but removes the possibility of overflow
On Dec 3, 2014, at 11:28 AM, Chris Toshok wrote:
A more compact implementation occurred to me during my commute: just have an
internal slot in the WC that it uses when looking up values, instead of the
WC reference itself.
This has the downside of not being able to purge old slots on
See https://bugs.ecmascript.org/show_bug.cgi?id=3383
The issue concerns things like this:
don't use strict;
var x=outer
function f(a=eval( var x=1; 42),
x=eval( console.log(can+(x!=1?'t:)+ see earlier eval
binding}; 84)
) {
console.log(x); // ? outer ,
Related to Andreas's points, if performance is a real concern here,
the dramatically inferior memory locality of a transposed weak map is
probably something that is at least worth thinking about. Cache
locality matters a lot in modern software, especially if you have a
large heap, and it will
'It remains possible to create clearless weakmaps to pass around (by
wrapping a weakmap, etc.), but it makes security (aka code robustness)
an opt-in and not the default.'
Seeing this sort of security-first argument when discussing a
user-space data structure is really confusing to me. If the
On Wed, Dec 3, 2014 at 2:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
See https://bugs.ecmascript.org/show_bug.cgi?id=3383
The issue concerns things like this:
don't use strict;
var x=outer
function f(a=eval( var x=1; 42),
x=eval( console.log(can+(x!=1?'t:)+ see
On 3 December 2014 at 23:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
See https://bugs.ecmascript.org/show_bug.cgi?id=3383
The issue concerns things like this:
don't use strict;
var x=outer
function f(a=eval( var x=1; 42),
x=eval( console.log(can+(x!=1?'t:)+ see
Le 03/12/2014 19:10, Jason Orendorff a écrit :
On Wed, Dec 3, 2014 at 9:04 AM, David Bruantbruan...@gmail.com wrote:
A script which builds a weakmap may legitimately later assume the weakmap is
filled. However, passing the weakmap to a mixed-trusted (malicious or buggy)
script may result in
Hi,
Are there any plans to add resize and movement event listeners for DOM
elements?
elem.addEventListener(move, function(e) {
console.log(o.target.oldLocation);
console.log(o.target.newLocation);
});
Are there technical limitations why these events or not being defined for
elements?
21 matches
Mail list logo
