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

Re: FileList (and other Array-like types)

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 29 May 2013 21:37:16 -0700
Message-ID: <CA+c2ei-GiEciKMYfC43dPg7aG3w68Cjkwp3hY94ktb8mpt+LxA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, Arun Ranganathan <arun@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>
On Wed, May 29, 2013 at 8:43 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/29/13 11:34 PM, Jonas Sicking wrote:
>> For 1 this seems to work fine. sequence<File> in WebIDL maps to a plain
>> JS Array. Though we might want to return an array that is frozen so that
>> multiple consumers couldn't interfere with one another.
> "sequence" in WebIDL is unfortunately overloaded. It not only means a plain
> JS array, it also means "pass by value".
> So for example WebIDL does not allow sequence types as attributes, because
> otherwise foo.files == foo.files would test false, since it would be a new
> array each time...
> This keeps coming up, though so far when people who want to return arrays
> from attributes were asked about modifications they've mostly not had a good
> answer.  Freezing might be a reasonable possibility.
> The construct WebIDL theoretically provides for this is File[] (in this case
> a readonly one), which is not an actual JS Array but sometimes quacks like
> one in some ways.  But not in others.

So sounds like File[] defeats the whole purpose of what I'm
suggesting, which is to avoid introducing new types and instead use
plain JS-Arrays.

So yeah, sounds like we need new WebIDL here, or have any spec which
currently returns a FileList instead use prose to describe how things

>> For 2 it's a bit trickier. We could define that the .files setter takes
>> a sequence<Blob> and that the getter returns a different sequence<Blob>.
> That's always the case for sequences, since sequences are passed by value.
> Except of course that you can't even have an attribute whose getter returns
> a sequence at the moment....
>> There is a question of if we for 2 want things like
>> myInputElement.files.push(new Blob(...));
>> to work. I.e. should you not just be able to set a new array, but also
>> mutate the existing array. A tricky part is that the implementation
>> needs to react to modifications to the array.
> This too, in theory, File[] (fixed-length, this time), is supposed to be
> able to do.  At least as long as you're OK throwing on
> myInputElement.files.push(5).

This is an interesting question. I actually do like having
myInputElement.files.push(5) throwing, but that would preclude using a
real JS Array?

So the question is. Which of the following solutions should we use:

A) Make myInputElement.files return a frozen array. I.e. forbid
.push-ing anything.
B) Make myInputElement.files not return a JS-Array.
C) Make myInputElement.files.push(5) allow the value to be pushed and
silently ignored.
D) Make myInputElement.files.push(5) allow the value to be pushed and
but make the Object.observe hook remove the value.

I'm partial to A myself. Do JS libraries elsewhere return Array
objects and then let the caller mutate that array as a way to pass
information to the library?

/ Jonas
Received on Thursday, 30 May 2013 04:38:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC