Le 06/06/2014 18:16, Nicholas C. Zakas a écrit :
On 6/6/2014 8:38 AM, Mark S. Miller wrote:
But the concern Nicholas raises doesn't seem to have this
property. Reading a property that doesn't exist doesn't carry a
security risk, does it? Object.preventUndeclaredGet doesn't
really protect against anything like ES5 methods did.
That's true, but misses the point I was trying to make. For normal ES
objects, it is already part of their API contract with their clients
that the clients can do feature testing to detect the presence or
absence of a method. The most common way to do such feature testing
is to get the property and see if it is falsy. (Variations include,
testing for undefined, testing for undefined or null, and testing if
its typeof is "function".) It's fine if the provider of an
abstraction does not wish to support this pattern. But it is not ok
for one client of an object which does support it to prevent that
object's other clients from successfully using feature detection.
Sorry I was sleeping while most of this conversation was happening. :)
I understand the point about feature detection, it would suck if some
random code did Object.preventUndeclaredGet() on an object you own and
were using feature detection on. I still wish for some way to do this
other than through proxies, but I agree that it would be nice for just
the object provider to be able to set this behavior.
It is possible via an API following the same pattern than revocable proxies:
{object, toggle} = makeUndeclGetThrowObject()
toggle(); // now the object throws when there is a [[Get]] on an
undef property
Keep the toggle function locally so only trusted parties access it,
share the object as you wish.
Admittedly more cumbersome than your solution or proxies :-p
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
