Re: Detecting the "type" of a DOM object

On Jun 21, 2012, at 1:30 PM, Boris Zbarsky wrote:

> On 6/21/12 4:11 PM, Allen Wirfs-Brock wrote:
> ...
>> 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?

Well, it's a educational issue and usually seems to reflect a lack of experience using dynamic languages.  I've found that people learn pretty quickly about the perf issues if they have them and a good profiler.   A more fundamental understanding usually comes as developers gain experience with this style of language.

> ...
> 
>>> 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_.

Well, if you know what insertBefore expects of its arguments you could try to check that.  But, really at that point it really is more insertBefore's problem.  Why, as its caller, are you trying to do its work for it?

> 
>> 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.

Right, and calling to into C++ code is a boundary crossing where you may need to do additional checking because C++ doesn't guarantee memory safety. 

>> 
>> 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?

The only real solution I know is to just avoid exposing such data structure to any user written code.   Or simply don't worry about it.   That's the framework writer perspective.  If integrity is critical then do what ever it takes to ensure it, even that the cost of reduced functionality.  But it isn't critical, let recognized that your code has no more integrity than that any random 

Allen