Re: [XHR2] responseType / response / overrideMimeType proposal

I don't think that performance should be very much of an issue since
.responseType would normally only be set once.  The performance hit is
negligible, and the string version seems to be clearer to use.

Chris

On Mon, Nov 29, 2010 at 11:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Nov 29, 2010 at 9:21 AM, Anne van Kesteren <annevk@opera.com>
> wrote:
> > Before I write it out it would be nice to assess whether there is
> consensus
> > on this. From the current draft, asBlob, responseBlob, and
> > responseArrayBuffer are removed. response and responseType are added.
> >
> > responseType can be set when the state is either OPENED or
> HEADERS_RECEIVED
> > and must be set before send() is invoked for synchronous requests. When
> set
> > at an inappropriate point it throws INVALID_STATE_ERR much like the other
> > attributes. (This means responseType can be set during the request,
> > specifically after all headers are available to the author so she/he can
> > make an informed choice what to set responseType to.)
> >
> > Depending on the type response either starts returning at LOADING or
> DONE.
> >
> > overrideMimeType can be invoked whenever responseType can be set.
> >
> > responseType has these constants:
> >
> >  RESPONSE_DEFAULT
> >  RESPONSE_TEXT
> >  RESPONSE_DOCUMENT
> >  RESPONSE_BLOB
> >  RESPONSE_ARRAY_BUFFER
> >
> > When set to anything but RESPONSE_DEFAULT responseText and responseXML
> will
> > throw INVALID_STATE_ERR. When set to RESPONSE_DEFAULT response returns
> what
> > responseText returns. (This seems mildly better than throwing, but I can
> be
> > convinced to make it throw instead.)
>
> I'm not really loving the enum names. Why not just loose the
> "RESPONSE_" prefix? There isn't a risk of name collisions anyway since
> the values are namespaced under the XMLHttpRequest name. I suspect
> that with names ranging from 27 to 35 characters, many of which are in
> upper case which is even more awkward to type, people will either just
> use the numeric values or define their own constants, both of which
> reduce the legibility of the code.
>
> I'd also be fine with using strings, but I personally like enums more
> (though the reason is mostly perf which is arguably pretty silly).
>
> / Jonas
>
>