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

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.

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.

(As an aside, I wish private symbols were still in the cards, so we could explain this in terms of JavaScript instead of bracket-bracket properties. I suppose a non-configurable non-writable property would work as well, but then it would be visible on the object, cluttering it up.)

Received on Wednesday, 7 August 2013 19:13:15 UTC