Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

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