OK, thank you Darin :) This alleviates the naming tension.
FileReader, FileException, and FileError it is, then.
(Eliminating Blob from the inheritance hierarchy causes the problems Darin mentions below).
On Mon, Aug 30, 2010 at 10:52 PM, Anne van Kesteren < annevk@opera.com > wrote:
On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher < darin@chromium.org > wrote:
Another idea (possibly a crazy one) would be to eliminate Blob, and just use File for everything. We could rename BlobBuilder to FileBuilder and have it return a File instead of a Blob. Same goes for Blob.slice(). Of course,
the File would not necessarily correspond to a real physical file on disk
for performance reasons.
Not having Blob at all works for me!
I gave this some more thought. Here's some issues I came up with:
1) BlobBuilder -> FileBuilder
This renaming seems to suggest the creation of a file, which is not the intent at all.
2) XHR.{asBlob,responseBlob} -> XHR.{asFile,responseFile}
This renaming seems to suggest the creation of a file, which is not necessary for small responses.
3) Combine Blob and File into a single File interface
This merging has the unfortunate side-effect of introducing a "name" property for the result of a
File.slice() operation. It also means that the result of FileBuilder and XHR.responseFile would
have a name.
Considering the above, it seems like there is a place for Blob (or something like it).
I can see Jonas' points about BlobReader vs. FileReader, and so I'm happy to backpedal and go with
FileReader, FileException, and FileError, keeping Blob for cases where we don't promise a file.
-Darin