- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 11 Nov 2010 13:28:18 +0100
- To: "Chris Rogers" <crogers@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "David Flanagan" <david@davidflanagan.com>, "Boris Zbarsky" <bzbarsky@mit.edu>, public-webapps@w3.org, "Jonas Sicking" <jonas@sicking.cc>, "Maciej Stachowiak" <mjs@apple.com>, "Geoffrey Garen" <ggaren@apple.com>, "Darin Fisher" <darin@chromium.org>, "Anne van Kesteren" <annevk@opera.com>, "Eric Uhrhane" <ericu@google.com>, michaeln@google.com, "Alexey Proskuryakov" <ap@webkit.org>, jorlow@google.com, jamesr@chromium.org
On Thu, 11 Nov 2010 00:00:59 +0100, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers <crogers@google.com> wrote: >>> >>> After discussion with Anne and James, I retract my support for a new >>> constructor. I'm in favor of .responseType. >>> >>> Specifically, .responseType would take values like "" (for legacy >>> treatment) / "text" / "document" / "arraybuffer" / "blob" / etc. If >>> the value is "", then .responseText and .responseXML are filled >>> appropriately, while .response is empty. Otherwise, .responseText and >>> .responseXML are empty (or throw or something), while .response >>> contains the value in the chosen format. .responseType must be set at >>> some appropriately early time; after the response is received, changes >>> to .responseType are ignored or throw. >>> >>> ~TJ >> >> So you prefer that .responseType take a string value as opposed to an >> integer enum value? Darin Fisher had the idea that introspection of the >> supported values would be easier as an enum. > > Yes, I think using an enum would be *extremely* verbose, particularly > given this particular API's name. I don't want to see or type code > like: > > myXHR.responseType = XMLHttpResponse.RESPONSETYPE_ARRAYBUFFER; > > This is much better: > > myXHR.responseType = "arraybuffer"; Constants are available on the object instance as well, so you can write: myXHR.responseType = myXHR.RESPONSETYPE_ARRAYBUFFER; -- Simon Pieters Opera Software
Received on Thursday, 11 November 2010 12:28:53 UTC