To me, the name "weakmap" means weakkey *and* weakref (weak value), and that is what I'd like: to be able to create a link (map) between two arbitrary objects, where the link only exists if both sides are still valid, and is killed (GC'd) if either or both go away. This type of functionality is useful for a system like a generalized event triggering mechanism, for instance. It's also useful for a devtool like an HTML inspector which needs to link a main-page DOM object to a representation DOM object in the tool. When I brought up this idea in IRC awhile back I suggested the name "ReallyWeakMap". :)
Yes, I'm aware of the reasons why weakrefs aren't in JS....I just still think it's a shame that we can't figure out a way for GC of weakrefs not to "leak" info to separate security sandboxes.
Anyway, why couldn't we just call it "Map" or "KeyMap" and drop any mention of "weak"?
--Kyle
On Sep 14, 2011 6:20 PM, Mark S. Miller <[email protected]> wrote:
On Wed, Sep 14, 2011 at 6:04 PM, Juan Ignacio Dopazo <[email protected]> wrote:
On Wednesday, September 14, 2011, David Bruant <[email protected]> wrote:
> Also, I would like to talk a little bit about terminology. WeakMaps have
> their name inspired by the idea of "weak" references which have
> particular garbage-collection properties. From the developer
> perspective, this seems to be some sort of implementation detail they
> should not be aware of.
> As far as I know, current functions/constructors have their name
> inspired by the contract they fulfill rather than implementation
> considerations. The difference between current WeakMaps and Maps is
> their contract. In the latter, keys can be enumerated, in the former
> not. I think that this is the difference that should inspire different
> names rather than the implementation optimisation that is induced by
> this contract difference.
>In the last few days I had to write a piece of code that would strongly benefit from WeakMaps. I needed to store information about DOM nodes and retrieve it later, and these nodes aren't in my control so they can be detached at any time by someone else. If the references I kept were weak, I'd be sure that I wouldn't be causing a memory leak. And that's important in this case because the nodes are very likely Flash objects which can easily mean 20-50mb in memory. So knowing that a reference is weak is important information.
I agree.
Normally I strongly take the same position David does: emphasize semantics over implementation. But why? It is good when we can label a tool according to its purpose, rather than how it accomplishes that purpose. Associating the tool with its purpose helps us remember the right tool for the right job. Few would reach for the WeakMap tool thinking "I need a non-enumerable table". Granted, there are cases when the non-enumerability is the desired feature, but those cases are rare. The common purpose of a WeakMap is rooted in our understanding, at a high level, of certain implementation costs, and our desire to avoid certain avoidable implementation costs. Generally, that is what a WeakMap is *for*.
Cheers,
--MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
