Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
On Sep 11, 2012, at 1:07 AM, Cameron McCormack wrote: > Arun Ranganathan: >> I've pinged heycam to see if this is a proper use of the sequence type. I'm >> not sure it allows for such a variation in parameters. > > I agree with Boris, it makes sense to use sequence<> here. Whenever you just > want to take a list of values in an operation argument, and you don't want to > keep a reference to a platform array object, you should use a sequence<>. Done. http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob -- A*
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
Arun Ranganathan: I've pinged heycam to see if this is a proper use of the sequence type. I'm not sure it allows for such a variation in parameters. I agree with Boris, it makes sense to use sequence<> here. Whenever you just want to take a list of values in an operation argument, and you don't want to keep a reference to a platform array object, you should use a sequence<>. But I also agree with Glenn that if you did use T[], and the implementation knows that it will never use the temporary platform array object that gets created when converting the (for example) JS Array object, it should be able to skip the actual platform array object creation.
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
On 9/10/12 6:36 PM, Arun Ranganathan wrote: I've pinged heycam to see if this is a proper use of the sequence type. I'm not sure it allows for such a variation in parameters. Sequence allows any WebIDL type as a sequence element. So for example, you can do this: sequence<(sequence<(DOMString or Element or ArrayBufferView)> or DOMString)> Not that you should do such a thing. ;) -Boris
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
I've pinged heycam to see if this is a proper use of the sequence type. I'm
not sure it allows for such a variation in parameters.
-- A*
On Sep 9, 2012, at 2:31 PM, Boris Zbarsky wrote:
> On 9/9/12 12:13 PM, Glenn Maynard wrote:
>>In particular, a Blob represents immutable binary data. That means
>>that it has to copy the input anyway. Given that, it doesn't make
>>sense to pass the input by reference if the caller _does_ happen to
>>have an WebIDL array object.
>>
>> That doesn't mean it copies the array itself, though.
>
> That's true, but in most cases (certainly the ones where a JavaScript array
> will be passed in) that would happen anyway.
>
>> (Though both ways, this seems like an implementation detail
>
> It's not quite.
>
>> I'd expect a mature binding system to let you annotate implementations to say
>> things like "make a copy for me instead of passing it in by reference"
>> and "don't make a copy even though WebIDL requires it, because we
>> fulfill that requirement as a side-effect".)
>
> Those are both incredibly fragile. Consider some other random spec that has
> IDL like this.
>
> interface Foo {
>// Returns the argument passed to the constructor
>(ArrayBuffer or ArrayBufferView or Blob or DOMString)[]
> getInitData();
> };
> Blob implements Foo;
>
> Now suddenly your annotation is a bug.
>
> So in practice binding systems aren't particularly likely to implement such
> annotations because of the increased fragility they introduce. The whole
> point of having IDL for bindings is to _reduce_ fragility
>
> The upshot is that there are practical drawbacks (slowing down the common use
> case, as far as I can tell) and at best theoretical benefits (since nothing
> actually _produces_ platform arrays of the above union!).
>
> By the way, note that if something produces a DOMString[] and you pass _that_
> to a blob constructor as currently defined, then what will happen per spec is
> that the input will be converted to a sequence and then a new
> platform array object will be created and the sequence copied into it. So
> you'll still get passing by value, not by reference. The only way to get
> passing by reference is if you're given a T[] where T exactly matches your
> array element type.
>
> Basically, platform arrays are only useful if you both produce and consume
> them in the same interface, as far as I can tell...
>
> -Boris
>
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
On 9/9/12 12:13 PM, Glenn Maynard wrote:
In particular, a Blob represents immutable binary data. That means
that it has to copy the input anyway. Given that, it doesn't make
sense to pass the input by reference if the caller _does_ happen to
have an WebIDL array object.
That doesn't mean it copies the array itself, though.
That's true, but in most cases (certainly the ones where a JavaScript
array will be passed in) that would happen anyway.
(Though both ways, this seems like an implementation detail
It's not quite.
I'd expect a mature binding system to let you annotate implementations to say
things like "make a copy for me instead of passing it in by reference"
and "don't make a copy even though WebIDL requires it, because we
fulfill that requirement as a side-effect".)
Those are both incredibly fragile. Consider some other random spec that
has IDL like this.
interface Foo {
// Returns the argument passed to the constructor
(ArrayBuffer or ArrayBufferView or Blob or DOMString)[]
getInitData();
};
Blob implements Foo;
Now suddenly your annotation is a bug.
So in practice binding systems aren't particularly likely to implement
such annotations because of the increased fragility they introduce. The
whole point of having IDL for bindings is to _reduce_ fragility
The upshot is that there are practical drawbacks (slowing down the
common use case, as far as I can tell) and at best theoretical benefits
(since nothing actually _produces_ platform arrays of the above union!).
By the way, note that if something produces a DOMString[] and you pass
_that_ to a blob constructor as currently defined, then what will happen
per spec is that the input will be converted to a sequence
and then a new platform array object will be created and the sequence
copied into it. So you'll still get passing by value, not by reference.
The only way to get passing by reference is if you're given a T[]
where T exactly matches your array element type.
Basically, platform arrays are only useful if you both produce and
consume them in the same interface, as far as I can tell...
-Boris
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
On Sun, Sep 9, 2012 at 9:34 AM, Boris Zbarsky wrote: > In particular, a Blob represents immutable binary data. That means that > it has to copy the input anyway. Given that, it doesn't make sense to pass > the input by reference if the caller _does_ happen to have an WebIDL array > object. > That doesn't mean it copies the array itself, though. Unless your internal Blob representation is the same as the array you receive from your Blob ctor binding, you're going to end up making another copy anyway. (For example, you may be storing the underlying representations of the data rather than the JavaScript Blob objects themselves.) I'd also expect implementations to want to flatten other Blobs, so they don't need to be recursive. If you're passed [blob1, blob2], and blob1 itself is actually [blobA, blobB], you'd be storing [blobA, blobB, blob2], so there's no point in copying [blob1, blob2]. (Though both ways, this seems like an implementation detail. I'd expect a mature binding system to let you annotate implementations to say things like "make a copy for me instead of passing it in by reference" and "don't make a copy even though WebIDL requires it, because we fulfill that requirement as a side-effect".) -- Glenn Maynard
[FileAPI] Blob constructor should probably take a sequence, not an IDL array object
In particular, a Blob represents immutable binary data. That means that it has to copy the input anyway. Given that, it doesn't make sense to pass the input by reference if the caller _does_ happen to have an WebIDL array object. But worse yet, actual real-life callers call this with JS arrays. So the current IDL forces creation of a new WebIDL array object which is then thrown away because Blob makes a copy of the data anyway. Seems like a waste. -Boris
