On 18 July 2013 17:53, Brendan Eich <brendan at mozilla.com> wrote:
> Andreas Rossberg wrote:
>> On 18 July 2013 14:22, Claude Pache<claude.pache at gmail.com>  wrote:
>>> My suggestion is to allow wrapper objects to exist in the spec, but to
>>> completely hide them from the user by doing an implicit unwrapping whenever
>>> applicable. Thus, for any primitive class `P` (such as `Symbol`, `Bignum`),
>>> except for legacy ones (`Number`, `Boolean` and `String`).
>>>
>>> * `new P` produces an unwrapped value;
>>> * `p =>  Object(p)` becomes a no-op;
>>> * `Object.defineProperty`, Object.getPrototypeOf`, etc., return an
>>> unwrapped value when applicable;
>>> * plus some further details I've forgotten.
>>
>> I'm not sure I understand what this would achieve. AFAICS, it is
>> observably equivalent to making Symbol an object, no? So it would have
>> the exact same implications.
>
> What implications do you object to, though. We have trouble making symbols
> like unforgeable strings. They must have distinct typeof-type -- a symbol
> can't be "string" according to typeof.

Right, and nobody is suggesting that, AFAICT.

> We must avoid any wrapper converting
> to a string when used as a property name, per your
>
> ARB: The current spec has a toString for implicit conversion, which makes it
> too easy to convert the symbol to a string accidentally without realizing.
>
> from the March meeting notes. This leaves only three choices AFAICT:
>
> 1. Primitive symbol with Symbol auto-wrapper that throws when used as
> property name, the March consensus.

Fine with that. :)

> 2. (1) but with Claude's suggestion: auto-unwrap on use of Symbol as
> property name.

Not sure why bother. As you pointed out yourself, wrappers rarely ever
escape (otherwise we'd see far more complaints about if(Object(false))
and the like), so I don't think it matters much in practice.

But it wouldn't be too bad either. There would be a ToName conversion
that distinguishes wrapped symbols from other objects (perhaps based
on a new hint for ToPrimitive). This still has the advantage (over
making them exotic objects) that there is no auto-wrapping other than
the places where the spec already does ToObject, symmetrically with
other primitives. In particular, no special casing for equality,
keying, reflection, typeof, etc.

So I suppose I could live with that option.

> 3. Value object approach: no Symbol wrapper, typeof says "symbol", spec
> treats symbol as exotic object per latest draft.

The implementation cost of every new exotic object is fairly
substantial in a modern VM, due to cross-cutting. That's at least my
experience from implementing the ones currently on the ES6 radar,
proxies and symbols (not even considering optimisations). We should be
_very_ conservative about introducing more of these than absolutely
necessary.

/Andreas

On 18 July 2013 17:53, Brendan Eich <brendan at mozilla.com> wrote:
> What implications do you object to, though. We have trouble making symbols
> like unforgeable strings. They must have distinct typeof-type -- a symbol
> can't be "string" according to typeof.

Right, and nobody is suggesting that, AFAICT.

> We must avoid any wrapper converting
> to a string when used as a property name, per your
>
> ARB: The current spec has a toString for implicit conversion, which makes it
> too easy to convert the symbol to a string accidentally without realizing.
>
> from the March meeting notes. This leaves only three choices AFAICT:
>
> 1) Primitive symbol with Symbol auto-wrapper that throws when used as
> property name, the March consensus.

Fine with that. :)

> 2) (1) but with Claude's suggestion: auto-unwrap on use of Symbol as
> property name.

Not sure why bother. As you pointed out yourself, wrappers rarely ever
escape (otherwise we'd see far more complaints about if(Object(false))
and the like), so I don't think it matters much in practice.

But it wouldn't be too bad either. There would be a ToName conversion
that distinguishes wrapped symbols from other objects (perhaps based
on a new hint for ToPrimitive). This still has the advantage (over
making them exotic objects) that there is no auto-wrapping other than
the places where the spec already does ToObject, symmetrically with
other primitives. In particular, no special casing for equality,
keying, reflection, typeof, etc.

So I suppose I could live with that option.

> 3) Value object approach: no Symbol wrapper, typeof says "symbol", spec
> treats symbol as exotic object per latest draft.

The implementation cost of every new exotic object is fairly
substantial in a modern VM, due to cross-cutting. That's at least my
experience from implementing the ones currently on the ES6 radar,
proxies and symbols (not even considering optimisations). We should be
_very_ conservative about introducing more of these than absolutely
necessary.