give typeof its role and leave Array.isArray, Object.isObject,
Function.isFunction ... Whaveter.isWhatever it's easy to implement logic :-)
For classes it's fine to me to keep using the
{}.toString.call(something).slice(8, -1) trick ( Rhino engine as exception
but ... they can align with "[object " + [[Class]].name + "]" here )
for what I have seen, typeof has been always mainly used to grant an object
like reference, with the boring null exception ... I don't think developers
will complain about missing "array" also because I would expect typeof new
Number to be "number" at that point but this is misleading until primitives
exist
"function" is a must have because developers want to know about [[Call]] so
here comes the ambiguity problem between typeof and Object.isObject but
once these global public static methods are there I would keep typeof
simple/backward compatible as it has always been
br
OT: also with direct proxy Function.prototype could have a get(key) able to
/^is([A-Z][a-zA-Z$_]*)$/.test(key) return the right check for the generic
global/userDefined constructor through {}.toString.call(value).slice(8, -1)
=== RegExp.$1 check ... never mind, just random thoughts :-)
On Fri, Jan 20, 2012 at 1:20 AM, Brendan Eich <bren...@mozilla.com> wrote:
> Andrea Giammarchi
> <mailto:andrea.giammarchi@**gmail.com<andrea.giammar...@gmail.com>
>> >
>> January 19, 2012 4:10 PM
>>
>> for all WeakMap shims and examples I have seen this to guard the key as
>> object is basically:
>>
>> Object.isObject = function isObject() {
>> return Object(value) === value;
>> };
>>
>> why such difference with indeed function ambiguity with your first
>> example?
>>
>
> We agreed not to treat functions as non-"isObject" objects.
>
>
>> Agreed on Object.type since it's easy to monkey patch while typeof is
>> already causing my code to look like this
>>
>> typeof obj != "null" && typeof obj == "object" && !!obj
>>
>
> V8-proofing shows this, yeah. It's a good warning sign in addition to the
> sheer runtime incompatibility of changing typeof null to be "null".
>
> So Object.type is the thing to draft. Probably it should return
> typeof-like strings with the "null" fix and only that. I do not believe it
> should start returning "array" for Array instances, or take other
> experimental risks. But we should discuss.
>
> /be
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
