Andreas Rossberg wrote:
On 18 July 2013 14:22, Claude Pache<[email protected]> wrote:
IIUC, the problem with symbols-as-primitives is that, on one hand, wrapper
objects are not wanted, but, on the other hand, getting rid of wrappers leads
to complications.
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. 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.
2. (1) but with Claude's suggestion: auto-unwrap on use of Symbol as
property name.
3. Value object approach: no Symbol wrapper, typeof says "symbol", spec
treats symbol as exotic object per latest draft.
Is there a 4th choice?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
