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?
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
which looks a bit pleonastic ( since you like the word ) for code that
would like to run cross milestone and understand if the object is an object
and not a function ... however, now that I wrote it I understand concerns
about Object.type and the function case ...
br
On Fri, Jan 20, 2012 at 12:54 AM, Brendan Eich <bren...@mozilla.com> wrote:
> 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<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<https://mail.mozilla.org/listinfo/es-discuss>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
