> I would suggest updating the specification for Blob.slice() so that it > doesn't expect passing "undefined" for the second argument to have > identical behavior to not passing the argument at all. The "subarray" > method in the Typed Array spec [1], which has similar behavior to > slice(), doesn't mention the undefined value. > > I am afraid that this suggested change might not be preferred since we're > trying to mimic the behavior of Blob.slice to Array.slice and Array.slice > does allow passing undefined and treat it as omitting the value.
Jian, Can you clarify why we want Blob.slice to mimic Array.prototype.slice in this strange argument quirk? Let me suggest three reasons why we don't want Blob.slice to mimic Array.prototype.slice in this strange argument quirk: 1. Legacy argument quirks exist for legacy compatibility and nothing else. Since Blobs have no legacy requirements, they should not re-introduce the mistakes of JavaScript past. There are many legacy argument quirks in JavaScript. They often confuse programmers, rather than enabling them. For example, new Array(x) creates an array with ToInteger(x) elements in it, while new Array(x, y) creates an array with 2 elements in it, x and y. Would you mimic that quirk in Blobs if you could? 2. A Blob is not an Array. Blobs are incompatible with all other Array semantics. They don't have a length property. They don't support bracket access. They don't support destructive modification. If Blobs were like Arrays, you could just use Array.prototype.slice to slice a Blob. But you can't, because they're not alike at all. 3. Your specification doesn't actually conform to the exact semantics of all the argument quirks of Array.prototype.slice. There are a number of other quirks that you have left out because they are strange and you are not familiar with them. I will leave it as a thought experiment for you to go and find all the other quirks of Array.prototype.slice that you have missed. While you are seeking them out, you can meditate on whether you are making your API better or worse. Geoff
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
