W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2016

Re: Using objects for a mapping argument

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Mon, 26 Sep 2016 14:49:57 -0400
To: public-script-coord@w3.org
Message-ID: <1bc0877d-81c9-e2ed-0a60-b0953b910af9@mit.edu>
On 9/26/16 2:13 PM, Jeffrey Yasskin wrote:
> The more WebIDL-friendly version would look like:

They key point being whether what's passed in is an array of things 
which have id properties, or an id-to-value mapping.

Note that the "array of things" approach has the drawback of having to 
define what happens if the same id is present multiple times...

> I'm just using the array methods to map a function over a sequence.

The problem is a sequence is not a JS thing at all.  So you can't do that.

You can convert it back to an ES object and then do the map bit and then 
convert the ES bit back to a sequence.  Or you can just say that you 
create a new sequence of whatever type getService returns, by applying 
the algorithm steps of getService one by one to the values in your sequence.

Note that these two approaches are NOT black-box the same, 
unfortunately.  Specifically, they are not the same in the face of the 
page overriding Array.prototype[Symbol.iterator] or 
%ArrayIteratorPrototype%.next.  I'm not sure which behavior you want 
here, exactly, so I can't tell you which one you should do, but I 
_suspect_ you want to directly apply the getService steps to your given 
sequence of IDL values instead of round-tripping through ES and the 
iteration protocol.

> In at least one place, I forgot and just wrote a_sequence.map(). Have other
> specs picked a different convenient way to say that?

Not to my knowledge...

It might be worth to define a map operation for IDL sequences, indeed. 
We'd have to be careful to ensure that it is only defined when all the 
types match up nicely, because it would be bypassing all the normal IDL 
typechecking.

-Boris
Received on Monday, 26 September 2016 18:50:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 September 2016 18:50:35 UTC