Re: [Harmony proxies] add receiver as a first argument to all prototype-climbing traps
2011/4/5 David Bruant david.bru...@labri.fr Le 05/04/2011 10:22, Tom Van Cutsem a écrit : (...) If a browser does not support Object.freeze, seal or preventExtensions, it likely does not support fixing proxies either. Calling the fix() trap explicitly via Proxy.trap would still not lead to the expected behavior. Thinking about fix and the special TypeError||become behavior happening after the trap call, I think it would make sense that for the particular fix value, Proxy.trap would call the trap and do the TypeError||become behavior. I may be wrong, but I think that if a user calls Proxy.trap(fix), s/he expects the proxy to be fixed afterward. Following your design of allowing proxy users to explicitly call all traps, rather than special-casing fix, an alternative could be to introduce a Proxy.fix(proxy, pdmap) method that expects a property descriptor map and fixes the proxy, so that regular fixing would become expressible as |Proxy.fix(proxy, Proxy.trap(proxy,fix,[]))|. IIRC, an early version of the tracemonkey Proxy API had a method similar to Proxy.fix just for the sake of testing the fix trap, since it didn't support Object.freeze yet. But again, I would hope that an implementation that supports both Object.freeze + proxies just supports freezing proxies via the fix() trap as per the draft spec. I don't see the need for such an implementation to additionally provide an explicit mechanism like Proxy.fix. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript Object equivalence classes proposal
On Apr 3, 2011, at 11:12 AM, Allen Wirfs-Brock wrote: On Apr 2, 2011, at 5:11 PM, Brendan Eich wrote: Is multiple inheritance a use case that TC39 intends to address in a generic manner? No. Inheritance-based instanceof testing for the purpose of dynamic classification of objects is most appropriate in statically typed subclasing===subtyping languages. Multiple inheritance (at least for interfaces) is almost essential in such languages. That isn't is the case for dynamically typed subclassing!==subtyping languages. There is lots of experience with such languages that shows that dynamic classification via class or superclass inclusion testing is a poor practice. Thanks for filling in after my terse No. The countervailing force here is the DOM being implemented in C++ (or C in the old days) in browsers. Such implementations use nominal subtyping and it leaked right through into JS. This is not just an accident of history: implementors want fast is-a testing in the host programming language. Nevertheless, we are working on self-hosting the DOM, which should help dispel concerns about performance and scalability. I don't see a lot of instanceof checks in modern JS, even DOM-based JS, so I believe the nominal subtyping for performance argument is overstated. However, there are currently C++-implemented internal-to-the-DOM-and-browser code paths that do such is-a tests (e.g., event dispatch and bubbling). These need to be self-hosted, and the whole system benchmarked. We'll keep this list apprised of results. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript Object equivalence classes proposal
On Apr 5, 2011, at 2:19 PM, David Bruant wrote: What I'm worried about is the memory cost of such an implementation. The current [[HasInstance]] implementation has a constant memory cost. Keeping references has a linear memory cost in terms of instance number. My favorite real-world memory-intensive use case is the one-page Standard HTML (http://www.whatwg.org/specs/web-apps/current-work/). Right now, it contains 125684 DOM Elements. If trying to implement EventTarget [[HasInstance]] internal method, it would require as many entries in the WeakMap. First, there's no free lunch. Either the DOM objects need internal fields (vptrs in C++ sense, plus static shared vtbls) or brands or trademarks, which is per-object overhead. Or we need an entry in a weakmap for each object, which can be quite efficient (better if the map were a set, but still). Second, although the details do matter, the asymptotic space complexity is the same, ignoring static or singleton costs which amortize to epsilon: k*n for constant k and n objects, or O(n). The time complexity to test is-a would be O(1), but of course as David Bacon likes to point out, small constant factors can matter: a field load and compare beats a hashtable lookup. A C++ virtual call to QueryInterface or the like is slower than a well-implemented hashtable lookup. Again, big-O does not distinguish even if some benchmarks run on different implementations could tell. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Harmony proxies] add receiver as a first argument to all prototype-climbing traps
On Apr 7, 2011, at 7:49 AM, Tom Van Cutsem wrote: But again, I would hope that an implementation that supports both Object.freeze + proxies just supports freezing proxies via the fix() trap as per the draft spec. I don't see the need for such an implementation to additionally provide an explicit mechanism like Proxy.fix. Agreed. David, no need to overdesign for pathological partial-ES5 + Harmony-Proxies implementations! That's just a non-goal. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A few more module questions
On Apr 4, 2011, at 9:51 AM, P T Withington wrote:
On 2011-04-04, at 12:40, Sam Tobin-Hochstadt wrote:
Renaming:
- I find this syntax slightly unintuitive: import Geometry.{draw: drawShape}
At first glance this would mean for me: rename drawShape to draw. draw
feels to me like the result of the import.
This is based on the destructuring syntax, where this:
let {draw: drawShape} = ... some expression ...;
also binds the identifier |drawShape|.
FWIW, I read these destructuring patterns backwards too. Must be a
left/right brain thing. Something I will have to learn the hard way to make
it stick.
This does happen, but there's no way to fix it for you mano sinestro types
;-). The property identifier must be a compile-time constant and on the left of
:, so the variable name into which to destructure is on the right of :.
Fortunately there's a short-hand:
let {draw, move} = GraphixAPIObject;
where the property id also names the variable to bind.
It has been proposed that this shorthand be supported for structuring as well
as destructuring:
saveObject({draw, move});
would pass a new Object created as if by the initialiser ({draw: draw, move:
move}). The property id is treated as an identifier expression and evaluated to
get the property value.
We have some support for this on TC39 but it keeps dropping off the radar.
Comments welcome.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Question about Weak Maps
Weak Maps seems to have superseded ephemeron tables. They are non-enumerable, does this also exclude any call that gives you an array of the current keys? If this is the case then it excludes the primary use case we have in node for ephemeron tables. I can understand why you might want to limit enumerability because a gc could mutate the map during enumeration but I desperately hope there is still a way to get the current list of keys and inspect the values provided that you guard against the key going away. -Mikeal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Weak Maps
Why would you want to enumerate the keys in a weak map? Andreas On Apr 7, 2011, at 4:04 PM, Mikeal Rogers wrote: Weak Maps seems to have superseded ephemeron tables. They are non-enumerable, does this also exclude any call that gives you an array of the current keys? If this is the case then it excludes the primary use case we have in node for ephemeron tables. I can understand why you might want to limit enumerability because a gc could mutate the map during enumeration but I desperately hope there is still a way to get the current list of keys and inspect the values provided that you guard against the key going away. -Mikeal ___ 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: Question about Weak Maps
long post a while back about the security problems w/ enumeration on weak maps if you search for it. On Thu, Apr 7, 2011 at 6:13 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote: requests come in to a server, you want to stick them in a hash so that you can query the server at any time for all the current queries. the problem is that, when using objects, you'll always leak. there are too many reasons a request might go away and too many asynchronous owners of that request to reliably remove it from the hash, especially in node. ephemeron tables looked like a good way to solve this, we can stick them in the table and when nobody else has a reference to them they get collected. at any point we can query the server for all existing request/response objects. if we have no way to enumerate the map we can't do this. ___ 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: Question about Weak Maps
[Disclaimer: I'm not an expert at server code. That said...] Don't you generally need to manage the policy for these kinds of requests manually anyway? In particular, you can't actually tell if a user has abandoned their session, since the browser doesn't let you know when that's happened. So it's up to your server to decide what policies to use for expiring requests. With strong maps, you can do all this stuff explicitly, but it's not dependent on the GC: http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets With weak maps (which BTW are just a renaming of ephemeron tables), you depend on the GC for memory management, but you don't get enumeration. This was always the case with the design, even before the renaming. MarkM designed them this way in order to avoid security issues (he can probably explain these issues better than I), but there are portability issues as well: if you expose the current set of bindings in the table to programs, then they will be able to depend on the non-deterministic behavior of the GC. Experience shows that when specs introduce unspecified behavior, the web begins to depend on implementation-specific details. Dave On Apr 7, 2011, at 4:13 PM, Mikeal Rogers wrote: requests come in to a server, you want to stick them in a hash so that you can query the server at any time for all the current queries. the problem is that, when using objects, you'll always leak. there are too many reasons a request might go away and too many asynchronous owners of that request to reliably remove it from the hash, especially in node. ephemeron tables looked like a good way to solve this, we can stick them in the table and when nobody else has a reference to them they get collected. at any point we can query the server for all existing request/response objects. if we have no way to enumerate the map we can't do this. ___ 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: Question about Weak Maps
Hi Mikeal, I do not yet understand your server example. Perhaps a bit of illustrative code would help? In any case, within memory-safe gc languages, there are several well motivated enhancements of the API of the collector. Several of these are fundamental, in that there is no way to emulate them in their absence. Ephemeron tables aka WeakMaps is one. Weak references http://wiki.ecmascript.org/doku.php?id=strawman:weak_references is another. Given just a normal GC, neither can be emulated. Either one by itself is inadequate to emulate the other. WeakMaps are weak references were written as separate strawmen because, once separated, they are cleanly different abstractions. * WeakMaps by themselves do not make GC observable. They simply provide a collection abstraction designed to make each value accessible based on the *conjunction* of access to a WeakMap and to a key. Because access requires this conjunction of prior access, strong reachability of the value should likewise be based on strong reachability of both the WeakMap and the key. No other existing or proposed construct (including weak references) enables one to arrange such conjunctive reachability relationships. Were WeakMaps enumerable, then access to the WeakMap by itself would be an adequate condition to access its keys and therefore its values. * Weak references, especially when coupled with post mortem notification, is all about observing and reacting to collection decisions. By fetching a strong reference from a weak reference, the mutator (i.e., the program rather than the collector) can cause a non-monotonic transition of a value from non-strongly-reachable to strongly-reachable, provided it performs this fetch before the collector notices this non-reachability and collects that value. To do a distributed object system such as http://erights.org/elib/distrib/captp/ http://code.google.com/p/caja-captp/, we desperately need weak references and post mortem notification, in order to compose local collection into distributed acyclic collection. Because the ability to create weak references enables one to observe collection, and therefore enables one to read a high bandwidth covert channel, the ability to create weak references is a capability must not be given out lightly, and should be encapsulated by such distributed object systems (as it was in E). By contrast, the ability to create a WeakMap can be made generally available. * Local GC + WeakMaps + weak references with post mortem finalization are still not adequate to compose local collections into full distributed collection, including the collection of distributed cycles. http://erights.org/history/original-e/dgc/ explains a full distributed GC system designed by Arturo Bejar and implemented within (the language now known as) Original-E. It relied on adding a new API to the JVM collector (back in Java 1.0.x days IIRC), to obtain reachability-change information that cannot otherwise be derived from the local collector. Were the standardization process infinitely malleable I would write up a strawman for this as well, but my sense is that this would be a bridge too far for a standards process. Could your server example be handled by weak references with post mortem notification? Though I don't yet understand it, that would be my guess. I do intend to propose weak references for the next round of ES standardization after ES-next. On Thu, Apr 7, 2011 at 7:13 PM, Mikeal Rogers mikeal.rog...@gmail.comwrote: requests come in to a server, you want to stick them in a hash so that you can query the server at any time for all the current queries. the problem is that, when using objects, you'll always leak. there are too many reasons a request might go away and too many asynchronous owners of that request to reliably remove it from the hash, especially in node. ephemeron tables looked like a good way to solve this, we can stick them in the table and when nobody else has a reference to them they get collected. at any point we can query the server for all existing request/response objects. if we have no way to enumerate the map we can't do this. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Weak Maps
On Thu, Apr 7, 2011 at 9:11 PM, Mark S. Miller erig...@google.com wrote: Hi Mikeal, I do not yet understand your server example. Perhaps a bit of illustrative code would help? In any case, within memory-safe gc languages, there are several well motivated enhancements of the API of the collector. Several of these are fundamental, in that there is no way to emulate them in their absence. Ephemeron tables aka WeakMaps is one. Weak references http://wiki.ecmascript.org/doku.php?id=strawman:weak_references is another. Given just a normal GC, neither can be emulated. Either one by itself is inadequate to emulate the other. WeakMaps are weak references were written as separate strawmen because, once separated, they are cleanly different Oops. WeakMaps *and* weak references were ... abstractions. * WeakMaps by themselves do not make GC observable. They simply provide a collection abstraction designed to make each value accessible based on the *conjunction* of access to a WeakMap and to a key. Because access requires this conjunction of prior access, strong reachability of the value should likewise be based on strong reachability of both the WeakMap and the key. No other existing or proposed construct (including weak references) enables one to arrange such conjunctive reachability relationships. Were WeakMaps enumerable, then access to the WeakMap by itself would be an adequate condition to access its keys and therefore its values. * Weak references, especially when coupled with post mortem notification, is all about observing and reacting to collection decisions. By fetching a strong reference from a weak reference, the mutator (i.e., the program rather than the collector) can cause a non-monotonic transition of a value from non-strongly-reachable to strongly-reachable, provided it performs this fetch before the collector notices this non-reachability and collects that value. To do a distributed object system such as http://erights.org/elib/distrib/captp/ http://code.google.com/p/caja-captp/, we desperately need weak references and post mortem notification, in order to compose local collection into distributed acyclic collection. Because the ability to create weak references enables one to observe collection, and therefore enables one to read a high bandwidth covert channel, the ability to create weak references is a capability must not be given out lightly, and should be encapsulated by such distributed object systems (as it was in E). By contrast, the ability to create a WeakMap can be made generally available. * Local GC + WeakMaps + weak references with post mortem finalization are still not adequate to compose local collections into full distributed collection, including the collection of distributed cycles. http://erights.org/history/original-e/dgc/ explains a full distributed GC system designed by Arturo Bejar and implemented within (the language now known as) Original-E. It relied on adding a new API to the JVM collector (back in Java 1.0.x days IIRC), to obtain reachability-change information that cannot otherwise be derived from the local collector. Were the standardization process infinitely malleable I would write up a strawman for this as well, but my sense is that this would be a bridge too far for a standards process. Could your server example be handled by weak references with post mortem notification? Though I don't yet understand it, that would be my guess. I do intend to propose weak references for the next round of ES standardization after ES-next. On Thu, Apr 7, 2011 at 7:13 PM, Mikeal Rogers mikeal.rog...@gmail.comwrote: requests come in to a server, you want to stick them in a hash so that you can query the server at any time for all the current queries. the problem is that, when using objects, you'll always leak. there are too many reasons a request might go away and too many asynchronous owners of that request to reliably remove it from the hash, especially in node. ephemeron tables looked like a good way to solve this, we can stick them in the table and when nobody else has a reference to them they get collected. at any point we can query the server for all existing request/response objects. if we have no way to enumerate the map we can't do this. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Weak Maps
On Thu, Apr 7, 2011 at 9:15 PM, Mark S. Miller erig...@google.com wrote: On Thu, Apr 7, 2011 at 9:11 PM, Mark S. Miller erig...@google.com wrote: Hi Mikeal, I do not yet understand your server example. Perhaps a bit of illustrative code would help? In any case, within memory-safe gc languages, there are several well motivated enhancements of the API of the collector. Several of these are fundamental, in that there is no way to emulate them in their absence. Ephemeron tables aka WeakMaps is one. Weak references http://wiki.ecmascript.org/doku.php?id=strawman:weak_references is another. Given just a normal GC, neither can be emulated. Either one by itself is inadequate to emulate the other. WeakMaps are weak references were written as separate strawmen because, once separated, they are cleanly different Oops. WeakMaps *and* weak references were ... abstractions. * WeakMaps by themselves do not make GC observable. They simply provide a collection abstraction designed to make each value accessible based on the *conjunction* of access to a WeakMap and to a key. Because access requires this conjunction of prior access, strong reachability of the value should likewise be based on strong reachability of both the WeakMap and the key. No other existing or proposed construct (including weak references) enables one to arrange such conjunctive reachability relationships. Were WeakMaps enumerable, then access to the WeakMap by itself would be an adequate condition to access its keys and therefore its values. * Weak references, especially when coupled with post mortem notification, is all about observing and reacting to collection decisions. By fetching a strong reference from a weak reference, the mutator (i.e., the program rather than the collector) can cause a non-monotonic transition of a value from non-strongly-reachable to strongly-reachable, provided it performs this fetch before the collector notices this non-reachability and collects that value. To do a distributed object system such as http://erights.org/elib/distrib/captp/ http://code.google.com/p/caja-captp/, we desperately need weak references and post mortem notification, in order to compose local collection into distributed acyclic collection. Because the ability to create weak references enables one to observe collection, and therefore enables one to read a high bandwidth covert channel, It's worse than a high bandwidth covert channel, it's a high bandwidth side channel: https://mail.mozilla.org/pipermail/es-discuss/2010-September/011717.html. the ability to create weak references is a capability must not be given out lightly, and should be encapsulated by such distributed object systems (as it was in E). By contrast, the ability to create a WeakMap can be made generally available. * Local GC + WeakMaps + weak references with post mortem finalization are still not adequate to compose local collections into full distributed collection, including the collection of distributed cycles. http://erights.org/history/original-e/dgc/ explains a full distributed GC system designed by Arturo Bejar and implemented within (the language now known as) Original-E. It relied on adding a new API to the JVM collector (back in Java 1.0.x days IIRC), to obtain reachability-change information that cannot otherwise be derived from the local collector. Were the standardization process infinitely malleable I would write up a strawman for this as well, but my sense is that this would be a bridge too far for a standards process. Could your server example be handled by weak references with post mortem notification? Though I don't yet understand it, that would be my guess. I do intend to propose weak references for the next round of ES standardization after ES-next. On Thu, Apr 7, 2011 at 7:13 PM, Mikeal Rogers mikeal.rog...@gmail.comwrote: requests come in to a server, you want to stick them in a hash so that you can query the server at any time for all the current queries. the problem is that, when using objects, you'll always leak. there are too many reasons a request might go away and too many asynchronous owners of that request to reliably remove it from the hash, especially in node. ephemeron tables looked like a good way to solve this, we can stick them in the table and when nobody else has a reference to them they get collected. at any point we can query the server for all existing request/response objects. if we have no way to enumerate the map we can't do this. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A few more module questions
On Thu, Apr 7, 2011 at 12:20, Brendan Eich bren...@mozilla.com wrote:
Fortunately there's a short-hand:
let {draw, move} = GraphixAPIObject;
Given this, is there any reason for anything but import ModuleName.* then?
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
