es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References
On Fri, Feb 19, 2016 at 1:17 AM, Coroutines <coroutines at gmail.com> wrote:
Hi - I hope I am not suggesting something that has been said before ~
Having Proxy and eventual Weak References makes it possible to build Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++).
Not quite. This is why ephemeron collection makes such a difference. It can collect cycles that no arrangement of maps and weak references can collect. In particular, ephemerons are essential to build identity-preserving membranes with both necessary gc properties:
- While the membrane is up, collect across the membrane transparently, as if the membrane were not there.
- When the membrane is revoked, sever the reachability of all links crossing the membrane. A compartment fully inside the membrane can then be fully collected.
If you don't use ephemeron collection and you use the non-transposed representation, you will fail to collect membrane crossing cycles. If you don't use ephemeron collection and do use the transposed representation (as MS Edge currently does) then you will fail to sever reachability on revocation, failing to collect logically unreachable compartments.
Since collection across the membrane needs to happen much more often than cleaning up after revocation, best is ephemeron collection with the (Edge-like) transposed representation. Ephemeron collection without the transposed representation (as I think everyone but Edge currently does) makes normal collection across the membrane boundary much more expensive. But at least it does eventually clean up both kinds of garbage.
Map's API could just go away and follow traditional Object assignment and existence checks:
map[key] = value;
// wish JS had a null-coalescing
?operator like Coffeescript.. if (map[key] !== undefined || map[key] !== null) { ... }It's totally legal in non-Node JS to have Objects as keys in other Objects, right? (I forget)
Not sure where you got that idea, but aren't the objects just being converted to string property names?
On Fri, Feb 19, 2016 at 4:40 AM, Thomas Foster <thomasfoster at fastmail.com> wrote:
Not sure where you got that idea, but aren't the objects just being converted to string property names?
Huh. I was so certain Node allowed that - I guess I just never made use of it. I knew that 'legally' Map was the only place you could use an Object as a key, but someone told me a long time ago Node allowed this with normal Objects. I think I never noticed my err because whenever I wanted to use an Object as a key I always needed the weak reference property of WeakMap so I was required to use that anyway.
Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS..
On 2/19/16 3:50 PM, Coroutines wrote:
Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS..
I don't see how it could. I'll bet $50 someone out there is using obj[location] for example.
On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
On 2/19/16 3:50 PM, Coroutines wrote:
Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS..
I don't see how it could. I'll bet $50 someone out there is using obj[location] for example.
Yes, relying on the stringification behavior is very common. Absolutely no way to change it at this point without something like AWB's (abandoned) Object Model Reformation proposal strawman:object_model_reformation
that would allow changing the behavior of [].
On Fri, Feb 19, 2016 at 1:03 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
On 2/19/16 3:50 PM, Coroutines wrote:
Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS..
I don't see how it could. I'll bet $50 someone out there is using obj[location] for example.
Yes, relying on the stringification behavior is very common. Absolutely no way to change it at this point without something like AWB's (abandoned) Object Model Reformation proposal strawman:object_model_reformation that would allow changing the behavior of [].
Learning to dance around the broken relics of the old world forever... :(
On 02/19/2016 01:06 PM, Coroutines wrote:
On Fri, Feb 19, 2016 at 1:03 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
On 2/19/16 3:50 PM, Coroutines wrote:
Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS.. I don't see how it could. I'll bet $50 someone out there is using obj[location] for example. Yes, relying on the stringification behavior is very common. Absolutely no way to change it at this point without something like AWB's (abandoned) Object Model Reformation proposal strawman:object_model_reformation that would allow changing the behavior of []. Learning to dance around the broken relics of the old world forever... :(
Not in this case, imho. A string-keyed map is a very different data structure in my mind than an object-keyed map. An object-keyed map works off of object identity, which is straightforward until you start introducing value objects. But it also means that in order to look something up, you have to have the original object. That data structure is useful, and I'm glad we finally have it available as Map, but restricting property keys to strings (and Symbols) makes things a lot simpler both from users' and implementers' points of view. (We [SpiderMonkey] used to have object-keyed properties with E4X, and it was a nuisance.)
I hope I am not suggesting something that has been said before ~
Having Proxy and eventual Weak References makes it possible to build Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++).
I'd like to propose basing them off of these when Weak References are a 'thing'.
Map's API could just go away and follow traditional Object assignment and existence checks:
map[key] = value;
// wish JS had a null-coalescing
?operator like Coffeescript.. if (map[key] !== undefined || map[key] !== null) { ... }It's totally legal in non-Node JS to have Objects as keys in other Objects, right? (I forget)
So that's my idea. Toodles ~
PS: And build Set off of a Proxy + Array. Just stop being weird. :P
Hi - I hope I am not suggesting something that has been said before ~ Having Proxy and eventual Weak References makes it possible to build Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++). I'd like to propose basing them off of these when Weak References are a 'thing'. Map's API could just go away and follow traditional Object assignment and existence checks: map[key] = value; // wish JS had a null-coalescing `?` operator like Coffeescript.. if (map[key] !== undefined || map[key] !== null) { ... } It's totally legal in non-Node JS to have Objects as keys in other Objects, right? (I forget) So that's my idea. Toodles ~ PS: And build Set off of a Proxy + Array. Just stop being weird. :P