W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2015

Re: Array-with-item in WebIDL

From: Adam Klein <adamk@chromium.org>
Date: Tue, 23 Jun 2015 09:01:19 -0700
Message-ID: <CAEvLGc+s73XHJiDe4CS8ZfXnUqJ5FWoLWHJCNYpQnCyC=MDEqA@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Travis Leithead <travis.leithead@microsoft.com>, Joshua Bell <jsbell@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Jun 22, 2015 at 9:04 PM, Alex Russell <slightlyoff@google.com>
wrote:
>
> On Wed, Jun 17, 2015 at 8:59 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> FWIW, very few of the DOM APIs return array-like objects with a
>> "contains" function. It's much more common to return an object with a
>> "item" function. So if we were able to add "item" but not "contains"
>> that would still enable us to switch most of the APIs in question [*]
>> to use real JS Arrays.
>>
>> I'd also love to hear some thoughts about what we want Array.isArray()
>> to return for one of these objects. And would using a subclass of
>> Array accomplish that desired behavior?
>>
>> [*] Sadly NodeList is not one of the APIs in question since NodeList
>> needs to not be mutable through any Array mutator functions, but can't
>> use a frozen Array since it changes its contents. Fortunately NodeList
>> is an exception here.
>
>
> I don't think that's strictly true. NodeList changes *from the C++ side* are
> in fact reflected to others with references today, but the reverse is not
> true. Mutating an Array which represents this contents doesn't necessarialy
> need to reflect back to the C++ side, and because the contents (from the
> perspective of script) are updated by C++ at random points, they can be
> re-set by the C++ side whenever.
>
> NodeList can be an Array, it's just that the mutating methods need to not
> propagate back.
>

I don't understand how you'd see this working. Are you saying that author
code could be allowed to mutate NodeLists but that those mutations would be
overwritten later by C++? That seems like a very strange API:

var div = document.createElement('div');
var span = document.createElement('span');
var childNodes = div.childNodes;
div.appendChild(span);  // childNodes[0] is now span
var span2 = document.createElement('span');
childNodes[0] = span2;  // what is childNodes[0] now? span2?
div.appendChild(span2); // what's in childNodes now? maybe span2 twice?


>
>
> On Tue, Jun 16, 2015 at 3:01 PM, Allen Wirfs-Brock
>> <allen@wirfs-brock.com> wrote:
>> >
>> > On Jun 16, 2015, at 2:50 PM, Travis Leithead wrote:
>> >
>> > Perhaps this is heretical, but has anyone considered adding "item"
>> and/or
>> > "contains" to the native Array.prototype object in ES? If this is
>> indeed the
>> > web-compat blocker for dropping NodeList use in various DOM APIs, I'd
>> like
>> > to see if anyone could support this.
>> >
>> >
>> > TC39 investigated adding a method named "contains" to Array.prototype
>> be we
>> > discovered that it cause web breakage:
>> > https://github.com/tc39/Array.prototype.includes#status . Instead a
>> method
>> > called "includes" is on track to be added.
>> >
>> > "items" is a possibility, but past experience suggests that there is a
>> fair
>> > chance it would cause problems.
>> >
>> > Allen.
>>
>>
>
Received on Tuesday, 23 June 2015 16:01:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 23 June 2015 16:01:49 UTC