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

Re: FileList (and other Array-like types)

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 29 May 2013 23:43:35 -0400
Message-ID: <51A6CAE7.9040605@mit.edu>
To: Jonas Sicking <jonas@sicking.cc>
CC: public-script-coord@w3.org, Arun Ranganathan <arun@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>
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.

> 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 

I definitely agree we need _something_ here.  The current setup is 
fairly suboptimal in all sorts of ways.  :(

Received on Thursday, 30 May 2013 03:44:12 UTC

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