Jan 18 meeting notes

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Jan 19 16:53:55 PST 2012


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 <brendan at mozilla.com> wrote:

> Andrea Giammarchi <mailto:andrea.giammarchi@**gmail.com<andrea.giammarchi at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120120/9eeef7c2/attachment.html>


More information about the es-discuss mailing list