names [Was: Approach of new Object methods in ES5]

Brendan Eich brendan at mozilla.com
Fri Apr 16 19:01:47 PDT 2010


On Apr 16, 2010, at 2:31 PM, David Herman wrote:

>    function MyCustomKindOfNamespace() {
>        Object.becomePropertyName(this);
>        // ...
>    }

If arbitrary objects can be property names, are these objects weakly  
referenced? Or is the property an Ephemeron (key-value pair where the  
value is strong so long as the key is alive via other references,  
otherwise the value is weak and the property is liable to be removed  
along with the value being GC'ed)? This matters to avoid leaks and  
bloat involving cycles.

A Name object that is required to be a leaf in the live object graph  
has the advantage that it can be strongly referenced by the  
implementation when used as a property name (key), without reference  
cycles being possible. Implementations would be able to count on this  
property. We could choose to specify Names this way, and the current  
spec seems to lean this way.

Mark points out that if you treat Name objects as EphemeronTables,  
then for a given name object n, o[n] is n.get(o) (EphemeronTables  
can't be enumerated). I've argued the spec should not dictate this  
implementation, since other plausible ones exist that have different  
trade-offs (Name "objects" could be UUIDs, e.g.). Also, we don't want  
to couple proposals at this point if there is no semantic win in doing  
so.

There's an open question of what (typeof n) should be.


> PS Still, I have my doubts about using any such mechanisms for  
> versioning.

The topic is not versioning in full, rather hiding properties added to  
built-in prototypes.

/be


More information about the es-discuss mailing list