Jan 18 meeting notes

Brendan Eich brendan at mozilla.com
Thu Jan 19 15:54:31 PST 2012

> David Bruant <mailto:bruant.d at gmail.com>
> January 19, 2012 1:15 AM
> Le 19/01/2012 02:27, Waldemar Horwat a écrit :
>> Brendan: Kill typeof null.  Replace it with Ojbect.isObject?
> What would be the semantics of this?

It was not obvious but the precedent stems from the strawman that led to 
my proposal to change typeof null:


This week we considered the draft spec:

   Object.isObject = function isObject(value) {
       return typeof value === 'object'&&  value !== null;

to be deficient because a function is also an object, so one might 
rather have

   Object.isObject = function isObject(value) {
       return (typeof value === 'object'&&  value !== null) || typeof value == 'function';

> ------
> Object.isObject(null); // false
> Object.isObject({}); // true
> // so far so good :-)
> Object.isObject(function(){}) // ?
> ------
> I'd like to advocate "true" for the last case. For now, the best way 
> to test if something is of type Object (as defined in ES5.1 - 8.6, so 
> including function) is to do "o === Object(o)" (an alternative being 
> "o !== null && (typeof o === 'object' || typeof o === 'function')", 
> which is rather long and I have not seen much) which is a bit hacky 
> and not straightforward to read for those who are not familiar with 
> this trick.
> If an Object.isObject is introduced, I'd be interested in seeing it 
> covering the 8.6 definition.
> Or maybe introduce another function for this?

That came up too: Object.type(x) would be the new typeof. But it will 
take a while to get adoption, it's not built-in so monkey-patchable etc.
>> Use __proto__ in object literals to do a put (assuming that a 
>> __proto__ getter/setter was created in Object.prototype) instead of a 
>> defineProperty?  All modes or only nonstrict mode?
>> Allen: Make such use of __proto__ to be a synonym for <|.  If a <| is 
>> already present, it's an error.
>> DaveH: __proto__ is ugly.  Don't want it in the language forever.
>> Waldemar: What about indirect [] expressions that evaluate to 
>> "__proto__"?  In Firefox they evaluate to accesses that climb the 
>> prototype chain and usually reach a magic 
>> getter/setter-that-isn't-a-getter-setter named __proto__ that sits on 
>> Object.prototype.
>> MarkM: Likes the ability to delete __proto__ setter and thereby 
>> prevent anything in the frame from mutating prototypes.
>> Waldemar: How do you guard against cross-frame prototype mutations?
> With a bit of hope, this is not in use in the web now. One idea would 
> be that no __proto__ is defined on  otherFrame.Object.prototype, and 
> the frame would need to negociate with its parent to get the __proto__ 
> setting capability.
> This may break the web if currently there is a website which opens 
> iframes which relies on __proto__.

The threat model does not necessarily involve only cross-frame/window 


More information about the es-discuss mailing list