Feedback on the Relationship strawman

Tom Van Cutsem at
Thu Apr 11 01:39:11 PDT 2013

2013/4/11 David Bruant <bruant.d at>

> Hi,
> Feedback based on**doku.php?id=strawman:**
> relationships<>

Context: Mark and I have been putting this together after Mark's earlier
presentation of this idea at the previous TC39 meeting. We have been
privately discussing this with Sam and Allen, but haven't reached consensus
yet. We welcome input from the broader community.

> Curiosity question: What do "geti" and "seti" refer to? (the 'i'
> specifically)

"i" for "index" (the field is used as an index into the receiver object)

> Is it necessary for r to be able to be a string or a symbol? It looks
> superflous, but maybe there is a good reason.

First, I don't think Mark meant to propose a new concrete type
"Relationship". The word "relationship" (and the variable "r") is only used
as a collective to describe all the values that can be used as indices of
objects. In this light, an index r can be a string, a (unique) symbol, or a
(private) field.

The renaming from "private symbol" to "private field" is intentional:
unique symbols and private symbols ended up being very different, so better
to give them distinct names.

> In the [[GetRelationship]] algorithm, if r.[[Get]](@geti) is undefined,
> then return x.[[Get]](r) but what is this supposed to do if r is an object?
> x[r] would coerce r to a String before passing it to [[Get]], but here the
> object is passed directly without coercion. I feel this question is
> answered step 5.I of interaction with proxies which talks about
> stringification.
> I wonder if implicit stringification is necessary. I'm afraid most of the
> time, it'll mean "[Object object]" will be passed as key and result in an
> unexpected behavior (collision of keys, etc.)

Yes, but this is also the behavior we have today, right? Nothing new under
the sun. I even wonder whether we can change this, wouldn't it be

> I would be in favor to either do nothing or throw when
> r.[[Get]](@geti)/r.[[Get]](@**seti) is undefined. In any case, devtools
> can show a warning saying that r didn't have a @geti or @seti property if
> necessary.
> That the private "fields" make a relationship only to a value and don't
> follow the property descriptor path is a good feature. The idea of using
> Object.**getOwnPropertyDescriptor on private symbols has a bad taste to
> it.

Indeed. Another reason why we renamed "private symbols" to "private fields".

> It's not written in the strawman explicitly, but if this proposal is in,
> all the whitelist/unknownPrivateSymbol trap mess is going away. Probably
> for the best :-)


> It's taking me some time to understand the Map/WeakMap behavior. Sharing
> my understanding step by step:
>     var o = {};
>     var wm = new WeakMap();
>     wm.set(o, 12);
>     wm.get(o);
> WeakMap.prototype.set === WeakMap.prototype[@seti]
> So wm.set(o, 12); is equivalent to "o at wm = 12"
> And "o at wm" is equivalent to "wm.get(o, 12)", unless o isn't a key in
> which case o.[[Prototype]] is attempted. I don't understand the need to
> climb the prototype chain of the key.
> Hmm... It's true that in "o.azerty", 'azerty' is looked up on o, then its
> prototype, then its prototype, etc.

Exactly. The proto-chain walk was introduced to make private field access
resemble normal JS property lookup.
When this is not desirable, one can continue to use the plain WeakMap
get/set methods to associate state with an object.

> Nits: no need to declare 'this' as argument of [[(Weak)MapGetInherited]].
> Also, maybe you want to use the ES6 included [[GetPrototype]] instead of
> [[Prototype]] (I'm not sure about this one).

Yes, [[GetPrototype]] is probably the right internal method. The spec
language on the strawman page wasn't yet written to conform to the proper
ES6 style guidelines.

> Are there default @geti/@seti for Object.prototype?

Not sure if this is necessary: what would these default implementations do?
Probably just stringify their |this| value and use that as a string index.
That's no different from the current fallback semantics if @geti/@seti are

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list