- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 24 Oct 2011 19:23:38 -0700
- To: Ojan Vafai <ojan@chromium.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Eric U <ericu@google.com>, Webapps WG <public-webapps@w3.org>
On Mon, Oct 24, 2011 at 7:11 PM, Ojan Vafai <ojan@chromium.org> wrote: > On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr. <jackalmage@gmail.com> >> wrote: >> > On Mon, Oct 24, 2011 at 4:33 PM, Eric U <ericu@google.com> wrote: >> >> The only things that this lacks that BlobBuilder has are the endings >> >> parameter for '\n' conversion in text and the content type. The >> >> varargs constructor makes it awkward to pass in flags of any >> >> sort...any thoughts on how to do that cleanly? >> > >> > Easy. The destructuring stuff proposed for ES lets you easily say >> > things like: >> > >> > function(blobparts..., keywordargs) { >> > // blobparts is an array of all but the last arg >> > // keywordargs is the last arg >> > } >> > >> > or even: >> > >> > function(blobparts..., {contenttype, lineendings}) { >> > // blobparts is an array of all but the last arg >> > // contenttype and lineendings are pulled from the >> > // last arg, if it's an object with those properties >> > } >> >> The problem is that if the caller has an array, because this is a >> constructor, this will get *very* awkward to do until ES6 is actually >> implemented. > > We should pressure ecmascript to stabilize this part of ES6 early so that we > can implement it. That way we can start designing the APIs we want now > instead of almost the APIs we want. That said, I'm not opposed to the array > argument for now. We can always add the destructured version in addition > later. That's the route I would prefer to go yeah. > On the topic of getting rid of BlobBuilder, do you have thoughts on losing > the ability to back it by an on-disk file? I'm not sure I understand the problem. A Blob can also be backed by a on-disk file. Could you elaborate? >> You can't simply do: >> >> new Blob.apply(blobarray.concat("text/plain")); >> >> I *think* this is what you'd have to do in a ES5 compliant engine: >> >> new Blob.bind([null].concat(blobarray, "text/plain)); >> >> In ES3 I don't even think that there's a way to do it. Though that >> might not matter assuming everyone gets .bind correctly implemented >> before they implement |new Blob|. >> >> I don't think the complexity is worth it for a dubious gain. I.e. it's >> not entirely clear to me that the following: >> >> new Blob(blob1, blob2, mybuffer, blob3, "somestring", "text/plain"); > > > Could we make the first argument be the contenttype? That makes the vararg > version work better. As it is, "text/plain" could, theoretically be part of > the content. I guess that's an argument for only doing the array version. > Then the contenttype could come second and be optional. As I said, I don't > feel strongly about this. That only changes new Blob.bind([null].concat(blobarray, "text/plain")); to new Blob.bind([null].concat("text/plain", blobarray)); So I'm not sure it's a lot better :-) / Jonas
Received on Tuesday, 25 October 2011 02:24:36 UTC