W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2012

Re: Detecting the "type" of a DOM object

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 21 Jun 2012 14:28:52 -0400
Message-ID: <4FE367E4.3090009@mit.edu>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 6/21/12 2:14 PM, Allen Wirfs-Brock wrote:
> How often do you have (application) code that actually needs to discriminate between, for example, a DOM Node and a Date?

Any time you have a method that takes an argument it expects to be a 
Node and it wants to do argument validation up front instead of running 
into exceptions partway through when it's in an inconsistent state.

I've also seen requests for this from people doing introspection (for 
debugging, error reporting, etc).

> We also have the issue of what we mean by "is a".  Are we talking about behavioral equivalence or are you talking about identical implementation.

The former, in this case (witness the desire to have a Document test 
true for "is a Node").  If you just want identical implementation, you 
can get that now for WebIDL-defined stuff using 
Object.prototype.toString hackery.

> For example, in JS you might define:
>
> function isDomNode (obj) {
>     return 'nodeType' in obj;
> }

That tells you nothing about what will happen when you try to call 
insertBefore with obj as an argument....

> If an non-Node object has reached a point in the code where you expect an object that behaves like a Node you already have a bug.

Well, your _caller_ has a bug.  The idea is to catch the bug early and 
fail safe.  Especially for library code that has to deal with untrusted 
inputs.

-Boris
Received on Thursday, 21 June 2012 18:29:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:06 UTC