Feedback on the Relationship strawman

Tom Van Cutsem tomvc.be at gmail.com
Thu Apr 11 05:23:39 PDT 2013


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

>  Le 11/04/2013 10:39, Tom Van Cutsem a écrit :
>
>  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
> backwards-incompatible?
>
> I'm only interested in the semantics of the new syntax, so backward-compat
> isn't a concern.
> o1 at o2 coercing o2 to a string when it's an object would be consistent
> with what we have today, but I don't believe today's o1[o2] behavior is
> desirable. Maybe I'm wrong. Does anyone have examples of code making good
> use of the implicit o2.toString() for o1[o2]?
>

Ok, you're right. The new syntax does give us some leeway to change this
behavior. The benefit of sticking to current semantics is that refactoring
o[r] to o at r is less prone to unintended changes. But there's something to
be said for o at r never stringifying r.


>
>
>> Are there default @geti/@seti for Object.prototype?
>>
>
>  Not sure if this is necessary: what would these default implementations
> do?
>
> The same thing that private symbols would do.
>

Under this proposal, a private field (aka private symbol) is simply a
{Weak}Map. The @geti/@seti of a {Weak}Map will retrieve or store the
binding like its get/set methods would.

Normal Objects cannot store Object->Object bindings, only String->Object
bindings, so I don't see how the default @geti/@seti implementation on
Object.prototype could do the same thing as those on {Weak}Map.prototype.


>
>   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 undefined.
>
> I think I better understand the mismatch between what I understood and
> your intention.
> I expected relationship and the @ syntax to substitute to private symbols
> while it seems you "only" wanted to provide the basic mechanism that people
> can build on top of.
> Take the following example:
>     var o = {}, r = {}, r2 = {};
>
>     o at r = 12;
>     console.log(o at r); // 12
>     console.log(o at r2); // ?
>
> With the strawman as it is and string coercion, the second console.log
> would log 12 giving the false impression that o and r2 "have a
> relationship" or "are in a relationship" (is my wording confusing? :-s). I
> don't believe this is a good default.
>

I can see how this is confusing. Perhaps if, in o at r, r is neither a string
nor a unique symbol nor a private field, we should throw rather than coerce
to string. Deferring to Mark.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130411/36e96605/attachment.html>


More information about the es-discuss mailing list