Re: [websockets] Binary support changes

On Sat, 28 May 2011, Cameron McCormack wrote:
> Ian Hickson:
> > Consistency is good when it makes sense. However, I don't think XHR is a 
> > good parallel here. XHR has all kinds of additional complexities, for 
> > example it lets you get a string, whereas here string vs binary is handled 
> > at the protocol level and so can't ever be confused.
> > 
> > However, if we want consistency here anyway, then I'd suggest we change 
> > XHR to use the actual type values just like WebSockets. It would IMHO lead 
> > to much cleaner code.
> 
> The difference would just be specifying `"ArrayBuffer"` vs
> `ArrayBuffer`, right?

Actually XHR uses lowercase strings.


> I think the difference in cleanliness is minimal.

In JS today, the difference is that mistakes with a string throw an 
INVALID_STATE_ERR exception while mistakes with the interface objects are 
more likely to throw a ReferenceError.

In other languages, the difference is a compile-time vs run-time error.

"Other languages" could include JS compilers, in which case this could be 
a not trivial win for authors.


> Using strings as enumeration values is quite common in JS, but I don’t 
> think I’ve seen this idiom of using interface objects before.

I'm not aware of any other flags that decide what kind of type to return, 
only responseType and now binaryType.


The real question in my mind is why would we use a string when we don't 
have to? Strings are a terrible interface for enumerations, and an even 
worse one for types.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'