Re: Removal of WeakMap/WeakSet clear
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 asymmetry. By adopting what Allen and I refer to as the transposed representation (as opposed to your transposed representation), you'd instead be able to say of the common scenario In both minor or major collection both k and v are immediately reclaimed, because neither is strongly reachable at that point which would be much more valuable than any other efficiency issue discussed in this thread. What I'm saying is that this is a theoretical conclusion at which you arrive only under various simplifying and idealistic assumptions (such as life time being the only factor that matters). I maintain that there is no evidence yet that this actually translates to better overall performance in practice, and I have severe doubts that it would. I don’t want to reiterate the concerns that I already raised in an earlier thread, but the executive summary is: Good performance absolutely wants an object layout that is stable and compact. The transposed weak map implementation pretty much is an antithesis to that. It hence induces a potential cost on all key objects (and all their uses throughout a program) instead of just the maps. That is a case of optimising for the wrong thing as well. (Back to the actual topic of this thread, you still owe me a reply regarding why .clear is bad for security. ;) ) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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. Unlike Map.prototype.clear, WeakMap.prototype.clear is a capability that cannot be userland implemented. With WeakMap.prototype.clear, any script can clear any weakmap even if it knows none of the weakmap keys. 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 assumption of the weakmap being filled and trigger all sorts of bugs). Like all dumb things, at web-scale, it will happen. WeakMap.prototype.clear is ambiant authority which necessity remains to be proven. 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. Opt-ins are cool, but are often forgotten, like CSP, like use strict, like cookie HttpOnly, like HTTPS, you know the list :-) It would be cool if they were by default and people didn't have to learn about them all. Security by default is cooler in my opinion. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
iterating through object property values
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. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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 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. Unlike Map.prototype.clear, WeakMap.prototype.clear is a capability that cannot be userland implemented. With WeakMap.prototype.clear, any script can clear any weakmap even if it knows none of the weakmap keys. 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 assumption of the weakmap being filled and trigger all sorts of bugs). Like all dumb things, at web-scale, it will happen. WeakMap.prototype.clear is ambiant authority which necessity remains to be proven. 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. Opt-ins are cool, but are often forgotten, like CSP, like use strict, like cookie HttpOnly, like HTTPS, you know the list :-) It would be cool if they were by default and people didn't have to learn about them all. Security by default is cooler in my opinion. David ___ 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
Re: Removal of WeakMap/WeakSet clear
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 one single place, impossible to otherwise reproduce, that is the sole channel for messing with the Array contents. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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) to the WC? Then, something like this:
```js
WC.prototype.clear = function() { this.generation ++; }
WC.prototype.has = function(k) {
var slot = getWCSlot(k, this);
return slot slot.generation == this.generation;
};
WC.prototype.set = function(k, v) {
var slot = getWCSlot(k, this);
if (slot) {
// update the slot's information (including generation)
slot.generation = this.generation;
slot.value = v;
}
else {
k[@@weakContainers][this] = { generation: this.generation, value: v };
}
};
WC.prototype.get = function(k) {
var slot = getWCSlot(k, this);
if (!slot) return undefined;
if (slot.generation != this.generation) {
// purge the key's slot for this weakmap
delete k[@@weakContainers][this];
return undefined;
}
return slot.value;
};
```
Then clear()'s description can be changed to (if it wasn't this already)
simply: There is no way to retrieve values corresponding to keys added
prior to the clear()
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: iterating through object property values
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 problems in code (code which
probably ought to be using Object.create(null), but you know, doesn’t).
Caitlin Potter
On Dec 3, 2014, at 12:07 PM, Mark Volkmann r.mark.volkm...@gmail.com 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 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. Mark Volkmann
Object Computing, Inc.
___
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
Re: iterating through object property values
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 mitigates most of
these problems, but I’m not positive about that.
Caitlin Potter
On Dec 3, 2014, at 12:23 PM, Caitlin Potter caitpotte...@gmail.com wrote:
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 problems in code (code
which probably ought to be using Object.create(null), but you know, doesn’t).
Caitlin Potter
On Dec 3, 2014, at 12:07 PM, Mark Volkmann r.mark.volkm...@gmail.com 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 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. Mark Volkmann
Object Computing, Inc.
___
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
Re: Removal of WeakMap/WeakSet clear
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 assumption of the weakmap being filled and trigger all sorts of bugs). Like all dumb things, at web-scale, it will happen. OK. I read the whole thing, and I appreciate your writing it. There's something important that's implicit in this argument that I still don't have yet. If you were using literally any other data structure, any other object, passing a direct reference to it around to untrusted code would not only be dumb, but obviously something the ES spec should not try to defend against. Right? It would be goofy. The language just is not that hardened. Arguably, the point of a data structure is to be useful for storing data, not to be secure against code that **has a direct reference to it**. No? So what's missing here is, I imagine you must see WeakMap, unlike all the other builtin data structures, as a security feature. Specifically, it must be a kind of secure data structure where inserting or deleting particular keys and values into the WeakMap does *not* pose a threat, but deleting them all does. Can you explain that a bit more? I see the invariant you're talking about, I agree it's elegant, but to be useful it also has to line up with some plausible security use case and threat model. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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 (malicious or buggy) script may result in the weakmap being cleared (and break the assumption of the weakmap being filled and trigger all sorts of bugs). Like all dumb things, at web-scale, it will happen. OK. I read the whole thing, and I appreciate your writing it. There's something important that's implicit in this argument that I still don't have yet. If you were using literally any other data structure, any other object, passing a direct reference to it around to untrusted code would not only be dumb, but obviously something the ES spec should not try to defend against. Right? It would be goofy. The language just is not that hardened. Arguably, the point of a data structure is to be useful for storing data, not to be secure against code that **has a direct reference to it**. No? So what's missing here is, I imagine you must see WeakMap, unlike all the other builtin data structures, as a security feature. Specifically, it must be a kind of secure data structure where inserting or deleting particular keys and values into the WeakMap does *not* pose a threat, but deleting them all does. Can you explain that a bit more? I see the invariant you're talking about, I agree it's elegant, but to be useful it also has to line up with some plausible security use case and threat model. As Mark presented it in the meeting ( https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-19.md#412-should-weakmapweakset-have-a-clear-method-markm ): the mapping from weakmap/key pair value can only be observed or affected by someone who has both the weakmap and the key. With clear(), someone with only the WeakMap would've been able to affect the WeakMap-and-key-to-value mapping. (This is the same thing that David was explaining, but slightly different delivery) As I understand this explanation, removing clear() simply closes off a path that would otherwise allow for potentially malicious meddling—no more, no less. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: iterating through object property values
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 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. Mark Volkmann
Object Computing, Inc.
___
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
Re: Removal of WeakMap/WeakSet clear
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 (if 'generation' is a
uint32, e.g)
```js
WC.prototype.clear = function() { this.[[WCIdentity]] = new object(); }
WC.prototype.has = function(k) {
var slot = GetWCSlot(k, this.[[WCIdentity]]);
return slot !== undefined;
};
WC.prototype.set = function(k,v) {
var slot = GetWCSlot(k, this.[[WCIdentity]]);
if (!slot)
slot = CreateWCSlot(k, this.[[WCIdentity]]);
slot.value = v;
};
WC.prototype.get = function(k) {
var slot = GetWCSlot(k, this.[[WCIdentity]]);
return slot slot.value;
};
```
On Wed, Dec 3, 2014 at 9:20 AM, Chris Toshok tos...@gmail.com wrote:
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) to the WC? Then, something like this:
```js
WC.prototype.clear = function() { this.generation ++; }
WC.prototype.has = function(k) {
var slot = getWCSlot(k, this);
return slot slot.generation == this.generation;
};
WC.prototype.set = function(k, v) {
var slot = getWCSlot(k, this);
if (slot) {
// update the slot's information (including generation)
slot.generation = this.generation;
slot.value = v;
}
else {
k[@@weakContainers][this] = { generation: this.generation, value: v };
}
};
WC.prototype.get = function(k) {
var slot = getWCSlot(k, this);
if (!slot) return undefined;
if (slot.generation != this.generation) {
// purge the key's slot for this weakmap
delete k[@@weakContainers][this];
return undefined;
}
return slot.value;
};
```
Then clear()'s description can be changed to (if it wasn't this already)
simply: There is no way to retrieve values corresponding to keys added
prior to the clear()
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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 calls to has/get, but removes the possibility of overflow (if 'generation' is a uint32, e.g) Presumably one use for a clear operation is to release the association between the key and the value and hence enable GC of the value (if it has no other references). This approach won't accomplish that. It provides behaviorally clears the map but doesn't provide the potential GC benefits. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Scoping of non-strict direct evals in parameter expressions
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 , 1, or 84?
}
f();
In other words, for non-strict functions, in what scope does should a direct
eval that occurs in a parameter list expression context create its
declarations. Remember that formal parameters have their own scope contour
that is separate from the body scope (and the environment for the body scope
doesn't even exist during parameter expression evaluation. Also remember that
legacy non-strict direct evals within functions create vars (and functions) in
the variable scope of the function (which is the same as the body scope).
I propose, that for scoping purposes, we treat such evals (parameter expression
+ non-strict + direct) as if they were strict evals. That means that all
declarations created by the eval code are created in a new environment record
that is discarded when the eval completes. Basically, it means that evals in
parameter expression can't create bindings that are visible outside of the eval.
Also, note that I'm not proposing that strict mode rules such as banning 'with'
be applied to the body of the eval. I'm just talking about the declaration
scoping rules. This introduces a sort of micro-mode but the alternatives see
less desirable. They are 1) figure out a semantics of declarations injected
into the function from parameter list evals; 2) force parameter list direct
evals into full trict mode. The first is hard, complex, and probably
pointless; the second is still a sort of micro-mode, seems less aligned with
the likely user intent, and I think will actually be harder to specify.
Thoughts?
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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 impact the performance of both normal execution and collections. There are so many moving parts involved in implementing this container that it seems ill-advised to try and understand its overall performance just by looking narrowly at one specific aspect like whether or not reclaiming happens in a minor collection. In most real-world applications, you will see containers get used in many ways: write-once-read-many, write-many-read-once, write-many-read-many, etc. Immutable lookup tables, mutable short-lived state trackers for in-progress tasks, state associated with live 'entities' or other objects, etc. If the goal here is really to deliver the best possible performance, intuition experience from implementing WMs in (for example) v8 should in most cases trump the theoretical performance of the algorithm. Likewise, if performance is important, clearing is a common use case. There are certainly use cases where you don't want to clear, or don't need to, and in those cases it has been pointed out that the necessary infrastructure to clear MIGHT slow them down. But you want to optimize globally, where possible, so that the vast majority of use cases perform acceptably (no horrible, unusably slow cases) while trying to make as many of those cases fast as you can. So entirely ruling out clear() in order to optimize one case is potentially unwise there too. On 3 December 2014 at 06:35, Andreas Rossberg rossb...@google.com wrote: 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 asymmetry. By adopting what Allen and I refer to as the transposed representation (as opposed to your transposed representation), you'd instead be able to say of the common scenario In both minor or major collection both k and v are immediately reclaimed, because neither is strongly reachable at that point which would be much more valuable than any other efficiency issue discussed in this thread. What I'm saying is that this is a theoretical conclusion at which you arrive only under various simplifying and idealistic assumptions (such as life time being the only factor that matters). I maintain that there is no evidence yet that this actually translates to better overall performance in practice, and I have severe doubts that it would. I don’t want to reiterate the concerns that I already raised in an earlier thread, but the executive summary is: Good performance absolutely wants an object layout that is stable and compact. The transposed weak map implementation pretty much is an antithesis to that. It hence induces a potential cost on all key objects (and all their uses throughout a program) instead of just the maps. That is a case of optimising for the wrong thing as well. (Back to the actual topic of this thread, you still owe me a reply regarding why .clear is bad for security. ;) ) /Andreas ___ 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
Re: Removal of WeakMap/WeakSet clear
'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 stated goal of WeakMap is security, and this is a noble goal, why isn't the same true for the non-weak new containers like Map and Set? Immutable containers built-in to the standard library would certainly be a useful thing to have - people implement them in JS libraries all the time because they need them - so if that's in scope it seems like it should be a goal that's applied more evenly. As stated before, I believe the benefit of protecting people from having maps accidentally cleared may not outweigh the damage caused by having many applications out there with catastrophically bad performance due to clearing maps incorrectly (or expecting map clearing to be a sensible operation at all, when it isn't.) The underlying implementation and characteristics of WeakMaps are *really, profoundly strange* to anyone who doesn't know a lot about GCs and JS runtimes, if you ask me. A data structure that isn't understood is more likely to be misused. If we're talking about promoting overall code robustness, minimizing surprises in general seems like it should be a priority, and the underlying behavior of a transposed WeakMap - contained to everything else in the stdlib - is surprising. On 3 December 2014 at 09:04, David Bruant bruan...@gmail.com wrote: 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. Unlike Map.prototype.clear, WeakMap.prototype.clear is a capability that cannot be userland implemented. With WeakMap.prototype.clear, any script can clear any weakmap even if it knows none of the weakmap keys. 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 assumption of the weakmap being filled and trigger all sorts of bugs). Like all dumb things, at web-scale, it will happen. WeakMap.prototype.clear is ambiant authority which necessity remains to be proven. 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. Opt-ins are cool, but are often forgotten, like CSP, like use strict, like cookie HttpOnly, like HTTPS, you know the list :-) It would be cool if they were by default and people didn't have to learn about them all. Security by default is cooler in my opinion. David ___ 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
Re: Scoping of non-strict direct evals in parameter expressions
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 earlier
eval binding}; 84)
) {
console.log(x); // ? outer , 1, or 84?
}
f();
As it's now, it should be 84 seems, but with creation of `x` with the value
`1`, then printing `can see earlier eval binding`.
In other words, for non-strict functions, in what scope does should a
direct eval that occurs in a parameter list expression context create its
declarations. Remember that formal parameters have their own scope
contour that is separate from the body scope (and the environment for the
body scope doesn't even exist during parameter expression evaluation. Also
remember that legacy non-strict direct evals within functions create vars
(and functions) in the variable scope of the function (which is the same as
the body scope).
I propose, that for scoping purposes, we treat such evals (parameter
expression + non-strict + direct) as if they were strict evals. That means
that all declarations created by the eval code are created in a new
environment record that is discarded when the eval completes. Basically, it
means that evals in parameter expression can't create bindings that are
visible outside of the eval.
Yeah, since defaults params and the the whole intermediate params scope is
the whole new semantics, we can easily make this strict eval evaluation in
its isolated environment. Seems the easiest solution, so eventually the `x`
will be `outer`, and `can't see...`.
Dmitry
Also, note that I'm not proposing that strict mode rules such as banning
'with' be applied to the body of the eval. I'm just talking about the
declaration scoping rules. This introduces a sort of micro-mode but the
alternatives see less desirable. They are 1) figure out a semantics of
declarations injected into the function from parameter list evals; 2) force
parameter list direct evals into full trict mode. The first is hard,
complex, and probably pointless; the second is still a sort of micro-mode,
seems less aligned with the likely user intent, and I think will actually
be harder to specify.
Thoughts?
Allen
___
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
Re: Scoping of non-strict direct evals in parameter expressions
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 earlier
eval binding}; 84)
) {
console.log(x); // ? outer , 1, or 84?
}
f();
In other words, for non-strict functions, in what scope does should a
direct eval that occurs in a parameter list expression context create its
declarations. Remember that formal parameters have their own scope contour
that is separate from the body scope (and the environment for the body scope
doesn't even exist during parameter expression evaluation. Also remember
that legacy non-strict direct evals within functions create vars (and
functions) in the variable scope of the function (which is the same as the
body scope).
I propose, that for scoping purposes, we treat such evals (parameter
expression + non-strict + direct) as if they were strict evals. That means
that all declarations created by the eval code are created in a new
environment record that is discarded when the eval completes. Basically, it
means that evals in parameter expression can't create bindings that are
visible outside of the eval.
Also, note that I'm not proposing that strict mode rules such as banning
'with' be applied to the body of the eval. I'm just talking about the
declaration scoping rules. This introduces a sort of micro-mode but the
alternatives see less desirable. They are 1) figure out a semantics of
declarations injected into the function from parameter list evals; 2) force
parameter list direct evals into full trict mode. The first is hard,
complex, and probably pointless; the second is still a sort of micro-mode,
seems less aligned with the likely user intent, and I think will actually be
harder to specify.
Thoughts?
Sounds good to me. FWIW, I wouldn't consider this a micro-mode. It's
just scoping: every default expression simply executes in a new
(declaration) scope. You don't even need to change the rules for eval
itself, it can be specified completely independent of what the
expression is. If you model it that way, then it automatically extends
to future do-expression as well (which might also be abused to create
'var's in default expressions).
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Removal of WeakMap/WeakSet clear
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 the weakmap being cleared (and break the assumption of the weakmap being filled and trigger all sorts of bugs). Like all dumb things, at web-scale, it will happen. OK. I read the whole thing, and I appreciate your writing it. There's something important that's implicit in this argument that I still don't have yet. If you were using literally any other data structure, any other object, passing a direct reference to it around to untrusted code would not only be dumb, but obviously something the ES spec should not try to defend against. Right? It would be goofy. Object.freeze and friends were added to the ES spec for the very purpose of being able to pass direct reference to an object and defend against unwanted mutations. à propos d'une Is Object.freeze goofy? The language just is not that hardened. Arguably, the point of a data structure is to be useful for storing data, not to be secure against code that **has a direct reference to it**. No? The way I see it, data structures are a tool to efficiently query data. They don't *have* to be arbitrarily mutable anytime for this purpose. It's a point of view problem, but in my opinion, mutability is the problem, not sharing the same object. Being able to create and share structured data should not have to mean it can be modified by anyone anytime. Hence Object.freeze, hence the recent popularity of React.js. So what's missing here is, I imagine you must see WeakMap, unlike all the other builtin data structures, as a security feature. I'm not sure what you mean by security feature. Any API is a security feature of sort. Specifically, it must be a kind of secure data structure where inserting or deleting particular keys and values into the WeakMap does *not* pose a threat, but deleting them all does. Can you explain that a bit more? I see the invariant you're talking about, I agree it's elegant, but to be useful it also has to line up with some plausible security use case and threat model. The ability to clear any WeakMap anytime needs to be equally justified in my opinion. I'm curious about plausible use cases. What about making 'clear' an own property of weakmaps and make it only capable of clearing the weakmap it's attached to? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Element onResize and onMove events
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?
Best regards,
Behrang
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
