Re: Callback style for GetUserMedia (Re: First draft available)

[hat=individual contributor]
Thanks Robin, I think I understand the argument now.

In particular, I found this note:

> Note that similar threads to the one Anant pointed to have been raised in DAP, WebApps, Mozilla lists, the ScriptLib discussions. They're being captured inhttp://scriptlib-cg.github.com/api-design-cookbook/  (though much more work is needed on that).
>
and

> On one side we have something that's consistent with existing code in our community, well-anchored in convention, and more readable, and on the other we have Geolocation. I don't think Geolocation wins.
pretty compelling (once I understood the JS examples).
Count me as a supporter of the change.

                 Harald


On 12/01/2011 11:40 AM, Robin Berjon wrote:
> Hi Harald,
>
> On Dec 1, 2011, at 05:01 , Harald Alvestrand wrote:
>> On 12/01/2011 12:28 AM, Brian LeRoux wrote:
>>>> I'm a bit dense, but please bear with me .... what is the reason why this is
>>>> an advantage?
>>> code is more succinct / less indentation ceremony
>>>
>> the code for the callback will have another level of indentation
> I wouldn't put it that way. With the success/error approach, the error callback is always optional. This means that in the vast majority of cases, people just don't use it. Not handling errors is bad practice.
>
> If you contrast that with node-style callbacks, the error is right there — people handle it. This is not just theory: grab a random set of node-related GitHub code, you will see that people do something with the error they get, even if only logging it.
>
> Which brings about another value: consistency. The node style has become very common. A large body of JS developers now have experience with node, and if you have experience with node, you have experience with this pattern.
>
> This consistency has extra value as well in that it allows conventions to be used to plug things together. If you look at a module like async.js, it uses the fact that this convention is pretty much universal in node code to plumb together arbitrary callbacks that it knows nothing about. And it just works.
>
>> First case:
>>
>> function success(stream) {
>>    do something with stream
>> }
>>
>> function failure(err)
>>    do something with err
>> }
>>
>> function eithersuccessorfailure(err, stream) {
>>    if (err == ok) {
>>       do something with stream
>>    } else {
>>       do something with err
>>    }
>> }
> That's not how it's usually written. The error isn't ever ok: if it's defined there an error, if it's null there isn't. It mostly looks like:
>
> foo.doAsync(params, function (err, data) {
>      if (err) return doSomethingWithErr;
>      doSomething with data;
> });
>
> Even if you want to expand it a bit:
>
> foo.doAsync(params, function (err, data) {
>      if (err) {
>          doSomethingWithErr;
>          return;
>      }
>      doSomething with data;
> });
>
> You get everything including the call in a nicely laid out, always consistent manner.
>
> Another useful aspect is that with a single callback you usually inline it, which tends to flow better and be more readable. With multiple callbacks, inlining them in a row becomes hard to parse, and so your code gets littered with a million function fooSuccess and function fooError.
>
> On one side we have something that's consistent with existing code in our community, well-anchored in convention, and more readable, and on the other we have Geolocation. I don't think Geolocation wins.
>

Received on Thursday, 1 December 2011 11:02:49 UTC