- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Wed, 7 Aug 2013 19:11:51 +0000
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: Boris Zbarsky <bzbarsky@MIT.EDU>, Travis Leithead <travis.leithead@microsoft.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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