Fixing instanceof (Array.isArray() etc.)?

Herby Vojčík herby at mailbox.sk
Fri Jan 20 10:28:45 PST 2012


Axel Rauschmayer wrote:
> This JavaScript pitfall is still mind-boggling to me. It is clear what
> happens (each frame has a different copy of Array etc.), but I find it
> hard to wrap my mind around the consequences in practice. Is there a
> plan on how to make this less painful in the long run? Initially, a
> cross-frame version of instanceof might help (as opposed to
> Function.isFunction, Date.isDate, RegExp.isRegexp etc.).

Inspired by Smalltalk messages like #isInteger (defined in Object as 
returning false, defined in Integer as returning true) one possible 
solution would be to use variation of it. Its problem (or advantage, as 
one sees at it) is that it is designed for overwriting and possibility 
have forest, not only tree of objects that return isXxx as true; the is, 
for duck-typing. But if recent discussion of read-only inheritance 
proves true, then it can be protected by defining isArray property on 
(every) Object.prototype as non-writable, non-configurable, value:false, 
and similar one with value:true on (every) Array.prototype so one can 
not shadow it by mere assignment, but only by (explicit or implicit) 
defineProperty.

 From the point of security, it is probably too liberal. :-(

>
> --
> Dr. Axel Rauschmayer
> axel at rauschma.de <mailto:axel at rauschma.de>

Herby


More information about the es-discuss mailing list