Allen Wirfs-Brock wrote:
On Jul 15, 2013, at 8:35 AM, André Bargull wrote:
Allen (cc-ed) changed symbols back to objects in draft rev 16
(https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess
Object(x) will still work in ES6 to test for object types.
Correct, Symbols as primitive values were just causing too many
issues. Essentially, everyplace in the spec. that needs an object
had to be updated to explicit deal with Symbols. That certainly isn't
a pattern we want to follow in the future if add new "value types"
such as bignums. It's much cleaner to freeze the set of primitive
types and make all future value types (including Symbols) objects.
just as it would have been even cleaner if everything was an object
and there were not "primitive types".
+1.
Regarding, typeof. The right way to look at it is that the set of
results that correspond to non-object types will be fixed and includes
only ("undefined", "null", "number", "string", "boolean"). All other
typeof values correspond of objects (where an object is a value that
support the ES internal MOP).
(Regrets on lack of "null" typeof-result, of course.)
I'm updating my int64/uint64 experimental patch to return "int64" and
"uint64" typeof-types, to uphold these invariants:
typeof x == typeof y && x == y <=> x === y
If typeof 0L and 0UL were "object", this would fail, but we want 0L ==
0UL. This came up with decimal in the ES5 era, where 0m == 0 but 0m !==
0. It's generally a problem, not just for 0 but for many pairs of
numeric types subsuming a subset of the Integers where the values in
common should equate by == but not ===.
The (x === Object(x)) test evaluates to true for value objects in this
proposal, though. This may break code looking for "primitives" but we
need to see what such code expects. Is it filtering out the legacy
typeof-result primitives (plus "null"), trying to find values for which
typeof currently returns "object" or "function"? If so, I don't see a
problem: int64, bignum, etc. are not legacy primitives. Is this test
looking for objects that are their own wrappers? Again all is well,
unless "mutable wrapper" is assumed -- but that's not safe in the ES5
era to assume, anyway.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
