Re: FileList (and other Array-like types)

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 
myInputElement.files.push(5).

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

-Boris

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