I've prototyped int64 and uint64 value types, including Object.isValue
based on the strawman:
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
js> Object.isValue(null)
true
js> Object.isValue(undefined)
true
js> Object.isValue(true)
true
js> Object.isValue("hi")
true
js> Object.isValue(18446744073709551615L) // uint64 literal
true
js> Object.isValue({p: "foo"})
false
js> Object.isValue(function(){})
false
js> Object.isValue([1,2,3])
false
It's easy enough to revive your Object.isObject strawman that led to the
typeof null === "null" attempt:
js> Object.isObject(null)
false
js> Object.isObject(undefined)
false
js> Object.isObject(true)
false
js> Object.isObject("hi")
false
js> Object.isObject(42)
false
js> Object.isObject(18446744073709551615L) // uint64 literal
true
js> Object.isObject({p: "foo"})
true
js> Object.isObject(function(){})
true
js> Object.isObject([1,2,3])
true
Will this help enough? In time, perhaps. Let's see how it stacks up:
if (typeof x == "object") x.oops(); // buggy
if (typeof x == "object" && x) x.oops(); // fixed until value objects
if (typeof x == "object" && x != null) x.sigh();
if (Object.isObject(x)) x.yeah();
To handicap properly I use == not === since the types of operands are
guaranteed to make these operators equivalent in these particular uses.
Object.isObject wins on brevity and it's pretty clear -- the repeated
"Object" stem is a bit redundant but tolerable.
We should talk about reviving Object.isObject at the week after next's
TC39 meeting. I'll put it on the agenda.
/be
Douglas Crockford wrote:
On 5/8/2012 2:45 PM, David Herman wrote:
On May 8, 2012, at 9:19 AM, Rick Waldron wrote:
non-strict, non-opt-in:
typeof null === "null"; // false
implied opt-in:
Changing typeof null always seemed questionable to me in terms of value.
It doesn't really give you significant new functionality, it just kinda
seems "more sensible". But adding it would just make things *more*
messy, for very little gain. Since we can't eliminate the old typeof
semantics, we end up with the language having different semantics in
different contexts.
The issue isn't typeof null. null === is a more convenient test. The
issue is that typeof object gives a false positive when the value is
null. So sensing that a value is an object is error prone. We need a
simple, reliable test for objectness.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss