Yes. There are two opposite use cases. Both are necessary.


Use case for something like unique symbols / public symbols / guids /
funny-looking strings:

    Given that base at r = v succeeds at mutating something, we account
    for the mutable state as belonging to base. This allows r to be
    transitively immutable, and so sharable between subsystems that
    should not be able to communicate. All the unique symbols mentioned
    in the ES6 spec itself are of this form. Clearly, everyone (even across
    realms) must mean the same thing by @iterator, and so @iterator
    should not be mutable.

    When doing the operation across a membrane, where let's say the
    original of all three objects are on the other side of the membrane,
    it should be the proxy for the base object which traps the operation.
    Ideally, r should not be proxies, but should pass through the membrane
    in both directions untranslated.

    By trapping at the base, a base proxy which did not know r is able to
    obtain r in its trap handler.

Use case for something like private symbols / weak maps / fields:

    Given that base at r = v succeeds at mutating something, we account
    for the mutable state as belonging to r. This allows base to be
    transitively immutable, and so sharable between subsystems that
    should not be able to communicate. (Note that, although we account
    for the mutable state as belonging to r in the semantics, the
    implementation should *always* store the actual mutable state in
    the storage record implementing the base object, just as it would do
    for an internal property.)

    When doing the operation across a membrane, where let's say the
    original of all three objects are on the other side of the membrane,
    it should be the proxy for the r object which traps the operation.

    By trapping at r, an r proxy which did not know the base is able to
    obtain the base in its trap handler.




On Mon, Jul 29, 2013 at 4:16 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Dean Landolt wrote:
>
>> FWIW Jason convinced me in the end -- I was subtly misinterpreting the
>> spec.
>>
>
> Oh, my apologies!
>
> Allen, what say you? We should resolve this ASAP since engines are
> implementing ES6 for-of and iterators. Cc'ing Andy too.
>
>
>  I still believe symbols (or something like them) are really important,
>> just not necessarily for iterators.
>>
>
> Agreed.
>
>
>  I'd also like to echo the sentiment in favor of private symbols. Unique
>> symbols really don't offer much over GUIDs, and don't make a whole lot of
>> sense in a world without private symbols. And in a world with private
>> symbols unique symbols aren't strictly necessary.
>>
>
> Agreed again. Great to see convergence in people's thinking.
>
>  I don't fully grok the relationships strawman yet but it looks really
>> promising. I wonder what a /maximally minimal/ version of it might look
>> like -- if it could be stripped down enough to just accommodate the needs
>> of the es6 spec. while remaining palatable and leaving the door to private
>> symbols open? Anything to avoid GUIDs. I'd bet most everyone would concede
>> they're are a smell, an es-regret waiting to happen :)
>>
>
> Cc'ing Mark. If I understand correctly, the issue with relationships is
> the difference between weakmap as R and symbol as R. A weakmap is a mutable
> object so a side channel, a symbol is immutable (all the way down, which is
> not far because symbols are shallow).
>
> /be
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130729/591dfebb/attachment.html>

Yes. There are two opposite use cases. Both are necessary.


### Use case for something like unique symbols / public symbols / guids / funny-looking strings:

Given that base at r = v succeeds at mutating something, we account
for the mutable state as belonging to base. This allows r to be
transitively immutable, and so sharable between subsystems that
should not be able to communicate. All the unique symbols mentioned
in the ES6 spec itself are of this form. Clearly, everyone (even across
realms) must mean the same thing by @iterator, and so @iterator
should not be mutable.

When doing the operation across a membrane, where let's say the
original of all three objects are on the other side of the membrane,
it should be the proxy for the base object which traps the operation.
Ideally, r should not be proxies, but should pass through the membrane
in both directions untranslated.

By trapping at the base, a base proxy which did not know r is able to
obtain r in its trap handler.

### Use case for something like private symbols / weak maps / fields:

Given that base at r = v succeeds at mutating something, we account
for the mutable state as belonging to r. This allows base to be
transitively immutable, and so sharable between subsystems that
should not be able to communicate. (Note that, although we account
for the mutable state as belonging to r in the semantics, the
implementation should *always* store the actual mutable state in
the storage record implementing the base object, just as it would do
for an internal property.)

When doing the operation across a membrane, where let's say the
original of all three objects are on the other side of the membrane,
it should be the proxy for the r object which traps the operation.

By trapping at r, an r proxy which did not know the base is able to
obtain the base in its trap handler.