David Bruant <mailto:bruan...@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:
http://wiki.ecmascript.org/doku.php?id=strawman:object_isobject&rev=1295471005
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
attacks.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
