Le 16/06/2011 00:53, Mark S. Miller a écrit :
On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[email protected]
<mailto:[email protected]>> wrote:
In a way, the fixed properties proposal make proxies bicephal. For
some
inputs (property names), they plug their handler-provided
MOP-brain and
for some others, they plug a native object MOP-brain (ES5 - 8.12).
These
brains cannot communicate. This is why changing .length in the "native
object brain" has no effect in the other brain (which handles numeric
properties(...unless some of these are non-configurable)). And I think
it has been said before, but there would be no logging possible for
non-configurable properties in the context of the fixed properties
strawman since native MOP-brain doesn't allow that.
Cute metaphor. But as Tom's code showed, the proxy can create fixed
(non-configurable) accessor properties whose getters and setters form
a corpus callosum ;).
I think I see also a potential security issue. In Tom's code, getters
and setters of the non-configurable properties trigger code of what was
in the handler. This is useful as a user to keep triggering the get and
set traps, but it also leaks a reference to these functions (after a
call to Object.getOwnPropertyDescriptor). In the current proposal,
before a property becomes non-configurable, there is no access to any
trap (unless having access to the object which implies having indirect
access to all traps or the handler itself). After becoming a
non-configurable accessor property, the get and set trap applied to the
non-configurable properties become available as independant functions
that can be passed around.
Currently, one can revoke the access to an object with a
membrane/wrapper, but with the leak, I think that all getter/setters
will have to be wrapped as well (their call trap in particular)? Ok,
maybe there is no security issue, but it adds a little bit more work.
I was first enthousiastic by the general idea of keeping get/set traps
through getter/setters (came up first with the fix trap, I think), but
since there is an API allowing to extract these functions independently,
I'm not really sure it's a good idea (in general) anymore.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
