Yeah, this is easily a win for the web platform. Smaller, more concise
API. I like it.
As Ojan said; Please use rest params here so that there is no need to
create the extra array.
erik
On Mon, Oct 24, 2011 at 16:07, Rick Waldron <waldron.rick@gmail.com> wrote:
> From a real-world developer perpective, this API modification is a win.
>
> On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai <ojan@chromium.org> wrote:
>>
>> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> Hi everyone,
>>>
>>> It was pointed out to me on twitter that BlobBuilder can be replaced
>>> with simply making Blob constructable. I.e. the following code:
>>>
>>> var bb = new BlobBuilder();
>>> bb.append(blob1);
>>> bb.append(blob2);
>>> bb.append("some string");
>>> bb.append(myArrayBuffer);
>>> var b = bb.getBlob();
>>>
>>> would become
>>>
>>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>> I like this API. I think we should add it regardless of whether we get rid
>> of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
>> on ES6 fanciness to expand the array into varargs.
>> In theory, a BlobBuilder could be backed by a file on disk, no? The
>> advantage is that if you're building something very large, you don't
>> necessarily need to be using all that memory. You can imagine a UA having
>> Blobs be fully in-memory until they cross some size threshold.
>>
>>>
>>> or look at it another way:
>>>
>>> var x = new BlobBuilder();
>>> becomes
>>> var x = [];
>>>
>>> x.append(y);
>>> becomes
>>> x.push(y);
>>>
>>> var b = x.getBlob();
>>> becomes
>>> var b = new Blob(x);
>>>
>>> So at worst there is a one-to-one mapping in code required to simply
>>> have |new Blob|. At best it requires much fewer lines if the page has
>>> several parts available at once.
>>>
>>> And we'd save a whole class since Blobs already exist.
>>>
>>> / Jonas
>>>
>>
>
>