WeakMaps functionality, within regular object semantics
The "weak reference" semantics needs to apply to the entire collection in order to avoid key/value circularity induced leaks
Well, at least my powers of prediction haven't left me!
Thanks for humouring me.
Best,
Hugh
Isn’t that a general problem with weak references, though (one that they’d have to solve)? Does Java have that problem, too? But they do have finalizers.
I’d also expect the map management data to be tricky to manage with weak references.
On May 21, 2012, at 8:03 AM, Axel Rauschmayer wrote:
Isn’t that a general problem with weak references, though (one that they’d have to solve)? Does Java have that problem, too? But they do have finalizers.
I’d also expect the map management data to be tricky to manage with weak references.
Take a look at some of the references at the bottom of the Weak Maps wiki page harmony:weak_maps#see_also
On Mon, May 21, 2012 at 9:42 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
The "weak reference" semantics needs to apply to the entire collection in order to avoid key/value circularity induced leaks
I don't think this is quite right. The semantics need to refer to both (a) the object containing the entry and (b) the key of the entry. But nothing says that the object containing the entries has to be a WeakMap and not just any old object.
proposals. The syntax for it deviates from js' currently cohesive core object model, though; requiring getter and setter methods and having no literal format.
One alternative that may work neatly is a 'hold me weakly' operator. For example's sake, I'm going to use *, but there may be other eligible ones:
As a key:
var key = {} , obj = { *key: 'val' } // when
keyis eligible for GC, the key:value pair gets deletedobj[key] // -> 'val'; retrieval by
keydoesn't require the operatorAs a value:
var val = {} , obj = { key: *val } // likewise, when
valis eligible for GC, the key:value pair gets deletedAs both a key and a value:
var val = {} , key = {} , obj = { *key: *val } // when either
keyorvalis eligible for GC, the key:value pair gets deletedNon-literal form
var key = {} , val = {} , obj = {}
obj[*key] = *val // behaves the same as obj = { *key: *val }
I'm almost 100% convinced that the reason type of thing isn't in the proposal is that there's a some glaring semantic or implementation issue; but I thought it'd be worth mentioning anyway. If not only because of the comparative neatness of the syntax, perhaps also for helping keep the language cohesive as it grows.
Best,
Hugh
>From a user perspective, I'm really happy to see WeakMaps in the proposals. The syntax for it deviates from js' currently cohesive core object model, though; requiring getter and setter methods and having no literal format. One alternative that may work neatly is a 'hold me weakly' operator. For example's sake, I'm going to use *, but there may be other eligible ones: *As a key*: var key = {} , obj = { *key: 'val' } // when `key` is eligible for GC, the key:value pair gets deleted obj[key] // -> 'val'; retrieval by `key` doesn't require the operator *As a value*: var val = {} , obj = { key: *val } // likewise, when `val` is eligible for GC, the key:value pair gets deleted *As both a key and a value*: var val = {} , key = {} , obj = { *key: *val } // when *either* `key` or `val` is eligible for GC, the key:value pair gets deleted *Non-literal form* var key = {} , val = {} , obj = {} obj[*key] = *val // behaves the same as obj = { *key: *val } I'm almost 100% convinced that the reason type of thing isn't in the proposal is that there's a some glaring semantic or implementation issue; but I thought it'd be worth mentioning anyway. If not only because of the comparative neatness of the syntax, perhaps also for helping keep the language cohesive as it grows. Best, Hugh -- Hugh Jackson: Web Development Mobile: 0797 609 1579 Email: hughfdjackson at googlemail.com Code: github.com/hughfdjackson Twitter: @hughfdjackson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120521/083ba3b0/attachment.html>