Re: [XHR2] Readability of Async/Sync in xhr.open

On 2/27/11, Anne van Kesteren <annevk@opera.com> wrote:
> On Sun, 27 Feb 2011 21:51:12 +0100, Joseph Pecoraro <pecoraro@apple.com>
> wrote:
>> This gets especially hairy when the user + password parameters are
>> needed, and there is a "magic" boolean in the middle:
>> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-open-method
>>
>> Suggested values would be SYNC/ASYNC matching the spec's "async" boolean
>> name, or the longer SYNCHRONOUS/ASYNCHRONOUS.
>>
>> Is this something that would be considered, or is it so easy for authors
>> to make it clear, with comments or variable names, that it is not worth
>> it? Maybe I just need to remember what that boolean means!
>
The problem is just as you pointed out: You can't remember what they mean.

> I think if we want to do this we should apply the design consistently.
> There's many methods that take a boolean. cloneNode(), addEventListener(),
> etc. Not really sure whether it is worth it. For the magic boolan scenario
> we could maybe overload the method even further and introduce this:
>
> void open(DOMString method, DOMString url, DOMString user);
> void open(DOMString method, DOMString url, DOMString user, DOMString?
> password);
>
That looks like a proposal for `async` to be an optional middle arg, as in:
open(method, url[, async[, user[, password]]]);

If so, I'm not a fan of optional middle args. How do browsers handle
the case where `user` is a non-empty string and `async` is omitted, as
in:
  req.open("GET", ".", "JohnDoe");
?
[...]
>
> Another disadvantage is that the above is not backwards compatible and
> cannot be detected. You could only figure it out via browser sniffing. But
> after a couple of years you would have a slightly easier way to make
> asynchronous requests.
>
Did you test missing `async` but passed `user`? What were your results?
-- 
Garrett

Received on Monday, 28 February 2011 06:30:36 UTC