Re: Detecting the "type" of a DOM object

On 6/21/12 4:11 PM, Allen Wirfs-Brock wrote:
> This is usually just wishful thinking that is trying to apply static
> typing concepts to a dynamic language. What does an instanceof test
> actually guarantee about an object? Not much. For example, my reading of
> WebIDL says that most operations exists as configurable prototype object
> methods. These are over-ridable on a per instance basis and replaceable
> at the prototype level. So an simple instanceof test, any way you define
> it, isn't going to tell you anything about the future (or perhaps even
> the current) behavior of the object.

Well, yes, if you have to deal with malice, not just incompetence....

(There are ways to deal if you can save off things from the canonical 
prototypes before people can mess with them, but that gets complicated 
quicky.)

> There probably isn't a general language level solution to this for
> dynamic languages. If you aren't going to work through all those design
> issue for your specific application situation then you probably
> shouldn't even be thinking about early argument validation and just let
> the language engine do its job.

OK.  Can you convince the people who are nonetheless trying to do such 
early argument validation and complaining that it doesn't work of all this?

> Ok, but if you want behavioral equivalence (which I should probably
> define, roughly I mean exposes the same interface) then it can be based
> upon a constructor relationship (multiple different constructor can
> produce objects that are all behaviorally equivalent) or implementation
> mechanisms such as the [[Prototype]] chain.

Or neither, yes.

>> That tells you nothing about what will happen when you try to call
>> insertBefore with obj as an argument....
>
> If you care about insertBefore you can check for it instead of nodeType.

No, you can't.  I said obj as an _argument_.

> Short of a secure mechanism that
> guarantees you will call a known and trusted implementation of
> insertBefore

That's actually not that hard to provide in many cases.  For example, 
that's precisely what the various browsers guarantee to their extensions 
when those extensions operate on the page DOM, as long as the extensions 
themselves do nothing to subvert the guarantee.

> (and everything is uses or depends upon)

In at least the cases I'm familiar with it only uses and depends on C++ 
code that web pages can't mess with.

>> 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.
>
> What's "safe". The language guarantees memory safety. If you are worried
> about maintaining the invariants of you internal data structures, don't
> allow user code to directly access them.

The problem is one of being able to maintain internal data structure 
invariants in the face of possible exceptions on arbitrary property 
access, right?

> There are many situations where
> fail late is better than fair early. See, for example,
> http://www.cag.lcs.mit.edu/~rinard/paper/osdi04.pdf

Indeed.

-Boris

Received on Thursday, 21 June 2012 20:30:47 UTC