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