Re: Maybe we should think about Interface.isInterface functions again

On Aug 7, 2013, at 12:11 PM, Domenic Denicola wrote:

> Thanks for your help, an especially pointing out that obvious-in-retrospect naming conflict. Can't believe we missed that!
> 
> So, let us say we were trying to add this functionality to the platform. I think I am getting from your analysis that the best approach would be to assume there is some internal operation on each element, call it `[[QuerySelectorAll]]`, which is set up by `Element[@@create]`. (I will refrain from phrasing this in terms of private symbols since those seem to be on the chopping block.)
> 
> Then, of course, `Element.prototype.querySelectorAll` delegates to `this.[[QuerySelectorAll]]`. This neatly explains why `elementInstance.querySelectorAll(...)` works, but `Element.prototype.querySelectorAll(...)` and `Element.prototype.querySelectorAll.call(5, ...)` do not: because `Element.prototype` and `5` never had `Element[@@create]` called on them, so the internal property is not set up correctly.

More precisely, they weren't created by Element[@@create] so they don't have that prerequisite private state (however it is actually represented). 

> 
> With this in place, it's easy to explain the behavior of `Elements`: it simply calls `elementInstance.[[QuerySelectorAll]](...)`. If something ends up in the collection which is not a true element, i.e. has not been set up correctly by `Element[@@create]`, then it will fail, with some kind of error like "object 5 does not have method [[QuerySelectorAll]]."
> 
> This seems pretty good to me. I hope others agree.

this is essentially how all of the ES6 built-in methods that require a specific kind of object are specified. 

However, I caution against over using this pattern and being frugal in defining such restrictions.  (see http://www.wirfs-brock.com/allen/posts/379 "Web App Platform: Is it a Framework or it it an OS".)  Kernel-level operations need to have a very high-level of integrity. But there is probably many web APIs that don't need to be part of the platform kernel.  They are just parts of frameworks and can be operate with much lower integrity expectations.  As long as the kernel level operations are protecting themselves adequately the framework levels should not be able to crash the platform.  Poorly written code may case the framework layers to misbehave but that's just a buggy app.  The platform keeps running.

Allen