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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
