Hi David, yes, that code is just a stale illustrative example. This abstraction itself is not being used, and the code predates many changes to the proxy API that render it invalid. And even then, it was sloppy in ways you point out, e.g, regarding enumerability.
However, it is a good example of the kinds of abstraction that one could write using the modern proxy API, *if* we don't weaken the invariants it relies on. And again, the "read" function I pointed to is a production example which also relies on these invariants. On Sat, Jun 18, 2011 at 3:01 PM, David Bruant <[email protected]> wrote: > ** > Le 18/06/2011 05:35, Mark S. Miller a écrit : > > An even better example where Tom and I used these invariants, even if only > for an illustrative example, is < > http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_eventual_reference_proxy>. > The old text at the bottom of this old code says: > > "Note: localFarReferenceMaker should work even if obj is a host > object." > > A couple of things on this code: > * var pds = Object.getProperties(obj); > => strawman:extended_object_api suggests the name > "Object.getPropertyDescriptors" > > * var nonConfigurableOwnProperties = > Object.freeze(nonConfigurableProperties.filter(function(name) { > return !!({}).getOwnPropertyDescriptor.call(obj, name); }); > => I think the filter should be ({}).hasOwnProperty.call(obj, name); (no > need for !! since hasOwnProperty already returns a boolean) > > * isEnumerableOwn > => This is not a trap (anymore?) > > * In "enumerate" and "keys" traps, you do not take "enumerable" into > account, is it on purpose? > > * This abstraction does not take into account whether an property of obj > has later been set to "configurable:false". (But I don't know purpose of an > eventual reference, so it might be on purpose) > > * There are no defineProperty, getPropertyNames or getOwnPropertyDescriptor > traps (which are fundamental traps). Is it on purpose? > > > Were these invariants relaxed, abstractions such as this would either be > incorrect or be much less precise and therefore less useful. > > What is the purpose of this abstration? How is it used? > > On a slightly unrelated note, you use setTimeout(f,0) several times. I'd > like to point out that Malte Ulb very recently showed ( > http://jsperf.com/postmessage) that setTimeout(f,0) is not very good > performance-wise and that posting a message to oneself (window.postmessage) > is far more efficient. > This is neither part of ECMAScript, nor supported by all browsers (should > be by IE8, but the test doesn't work for a reason I have tried to find and > given up on), but in relevant contexts, i'll stop using setTimeout(f,0). > > David > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss

