On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers <crog...@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"; ~TJ