W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: BlobWriter simplification/split

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 02 Jul 2010 14:52:49 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, Web Applications Working Group WG <public-webapps@w3.org>
Message-id: <3CD440FE-891F-442E-80B7-400F4B4B88DD@apple.com>
To: Eric Uhrhane <ericu@google.com>

On Jun 30, 2010, at 10:29 AM, Eric Uhrhane wrote:

> On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> May I propose FileWriter in place of BlobWriter? ;-)
>> You are actually always writing to files, so it would make a lot of sense IMO.
> We renamed BlobReader based on the perspective that it took data from
> a Blob and read it into memory.  Likewise BlobWriter takes data from a
> Blob and writes it to a file.  I think the symmetry makes sense.
> Calling it FileWriter also works, but then you're naming by
> destination instead of source, so I don't think it complements
> BlobReader as well.

I think it makes sense to name writer objects by the destination rather than the source. It's normal to speak of reading from X, and writing to Y. You rarely say you are writing from Y. If you saw a random class called StreamWriter, would you expect it writes *to* a Stream, or *from* a Stream?

Put another way, the essence of this class is that it writes something to a file, not that it writes a Blob to some unspecified location. If we wanted to add functionality to write something other than a Blob to a File (such as, say, writing a typed array, or writing a string), then it would plausibly make sense as part of the same interface used for writing a Blob 
to a file. If we made an API to write a Blob somewhere else (such as to a memory location or somewhere on the network), it really would not make sense as part of the same interface.

Thus FileWriter.

I also think that the name Blob is pretty unpleasant and I would rather not increase its prominence in the API.

Received on Friday, 2 July 2010 21:53:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:09 UTC