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 <bzbarsky@mit.edu> 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