Re: QSA, the problem with ":scope", and naming

On Thu, Oct 20, 2011 at 7:23 AM, Alex Russell <slightlyoff@google.com> wrote:
> On Thu, Oct 20, 2011 at 3:14 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> On 10/20/11 7:18 AM, Alex Russell wrote:
>>>
>>> No we don't. The fact that there's someone else who has a handle to
>>> the list and can mutate it underneath you
>>
>> There is no sane way to mutate the list on the part of the browser if
>> someone else is also messing with it, because the someone else can violate
>> basic invariants the browser's behavior needs to maintain.
>
> Right. So you need to vend an apparently-immutable Array, one which
> can only be changed by the browser. I think that could be accomplished
> in terms of Proxies. But it's still an Array type.
>
>>> unless the argument is that the slots should
>>> be non-configurable, non-writable except by the browser that's also
>>> holding a ref to it.
>>
>> "Yes".
>>
>> Though I don't know what "slots" you're talking about; the only sane JS
>> implementation of live nodelists is as a proxy.  There's no way to get the
>> behaviors that browsers have for them otherwise.
>
> But it can be a Proxy to an *Array*, not to some weird non-Array type.

Let's do the general discussion about how live and non-live NodeLists
should behave in a separate thread.

The immediate question here is how should the returned object from
.findAll behave? Should it be mutable? Should you be able to insert
non-Nodes into it? Should it have all of the functions of
Array.prototype or just some subset? Should it have any additional
functions?

Since .findAll is a new function we have absolutely no constraints as
far as how NodeLists behave, we can simply return something that isn't
a NodeList.

/ Jonas

Received on Thursday, 20 October 2011 19:09:57 UTC