Re: Concerns about DOMRequest

On Feb 20, 2013 12:15 AM, "David Bruant" <bruant.d@gmail.com> wrote:
>
> Le 20/02/2013 02:06, Jonas Sicking a écrit :
>
>> On Tue, Feb 19, 2013 at 2:07 PM, David Bruant <bruant.d@gmail.com> wrote:
>>>
>>> Le 18/02/2013 16:35, Mounir Lamouri a écrit :
>>>
>>>> On 18/02/13 15:15, Marcos Caceres wrote:
>>>>>
>>>>> On Monday, 18 February 2013 at 09:50, Kenneth Rohde Christiansen
wrote:
>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>>> Examples Jonas showed using DOMFuture could just work with
DOMRequest
>>>>>>> if
>>>>>>> we add this .then() method.
>>>>>>>
>>>>>>> Also, we could imagine stuff like:
>>>>>>> getSomeData().then(function(data) {
>>>>>>> return getDataRelatedToThoseData(data);
>>>>>>> }).then(function(data) {
>>>>>>> show(data);
>>>>>>> });
>>>>>>>
>>>>>>> I have a patch for Gecko implementing that.
>>>>>>
>>>>>> I like this pattern. It also seems closer to what MS are using in
>>>>>> their Windows 8 JS APIs.
>>>>>
>>>>>
>>>>> Not that just adding .then() does not address other issues with the
API.
>>>>> David Braunt articulated this best in [1]:
>>>>>
>>>>> "In my opinion, one of the most absurd example is the DOMRequest thing
>>>>> which
>>>>> looks like:
>>>>> {
>>>>> readonly attribute DOMString readyState; // "processing" or "done"
>>>>> readonly attribute DOMError? error;
>>>>> attribute EventListener onsuccess;
>>>>> attribute EventListener onerror;
>>>>> attribute readonly any? result;
>>>>> };
>>>>>
>>>>> Read it carefully and you'll realize this is actually a promise... but
>>>>> it has this absurd thing that it has to have both an error and result
>>>>> field while only one is actually field at any given point.
>>>>
>>>> FWIW, DOMFuture has .value and .error too.
>>>>
>>>> Anyway, it's quite not clear why having .{value,result} and .error is a
>>>> bad thing. If the DOMRequest is used as a promise, it's unlikely those
>>>> fields would be used anyway. If those fields have to be used (ie. if a
>>>> consumer wants to access the result outside of a .then(), .done() or
>>>> promise-like methods)
>>>
>>> <digression>
>>> We can wonder whether this (need to access the value outside
>>> then/catch/done) ever happens. I have never had the need in a 8 months
>>> experience.
>>> I don't think I've seen a context in Gaia where that was the case either
>>> (where a value was needed outside the context of an onsuccess/onerror).
>>> Likewise for the state attribute, to be fully honest. I'm interested if
>>> others have different experience to share on this point, though.
>>>
>>> Recently, the best definition I have come up with for promises was [1]:
>>> "a promise is an event emitter of a unique "success" xor "error" event.
>>> .then/.fail replace addEventListener/on".
>>> This follows a set of reflections of the idea that objects shouldn't be
>>> thought as "properties+methods", but rather "properties+methods+events"
and
>>> some recurrent idioms (like promises and streams) are nothing but
>>> abstractions built on top of events.
>>> </digression>
>>>
>>> I haven't brought up this concern about the properties, because I feel
it's
>>> a minor one. My personal short-term goal is to help have Future/Promise
as
>>> soon as possible built in the platform whether they fit my own vision or
>>> not.
>>>
>>> I'm repeating what I've said elsewhere, but what we need for Futures to
be
>>> helpful:
>>> 1) chainable .then
>>> 2) (~optionally, but excellent for readability in some cases) chainable
>>> .fail/catch
>>> 3) .done to end the chain (and have the devtools report uncaught errors
at
>>> the end of the chain)
>>> 4) A combining mechanism à la Q.all
>>> This one could be optional and added as a library, but I fear people
will
>>> just mess up their libraries with off-by-one errors, etc., so it'd be
better
>>> to have it built-in.
>>> 5) the consumer of a promise can't resolve it
>>>
>>> Besides these 5 points, I personally won't fight over anything really
hard.
>>> The .result/.error properties are beyond these 5 points. The name
>>> Future/Promise is also beyond these 5 points :-p
>>
>> This sounds like excellent feedback into the DOMFuture work. I
>> personally agree with all of it except number 3. That seems like a
>> nice-to-have to me.
>
> I really insist on this one.
> One particularly annoying aspects of async programming is that you have
no stack trace you don't handle an error.
>
> f.then(function(){
>
>     })
>     .then(function(){
>         // an error is thrown here by library code and you didn't expect
it
>     })
>     .then(function(){
>
>     }).done()
>
> Without done, the unexpected error remains silent, your program doesn't
work, you have no idea why. When doing async testing, it often means one of
your async test just timeouts, which isn't very helpful.
> I just came across this yesterday on a Node project. Working with a
colleague, trying to pin down an issue, I sent him the stack trace, and he
just answered "useless, as usual", because that's really the experience of
async debugging. Promises/futures offer some hope.
> With done, you can be told an unhandled error happened. The Q library
throws the unhandled error (which no one really catches, because the error
is thrown in its own event loop turn), but that's a library. With native
futures, the devtools can log the error and that's largely enough.
> Additionally, with native support for DOMFuture, the devtools can know
exactly where the future comes from and can tell us which future was the
first one to be broken and provide the full list of all futures involved
(like a stack trace... let's call that a future trace?). Super helpful.
>
> When you use a future every once in a while, .done is a nice to have. If
you use chained futures extensively all over your code, .done really makes
a difference.

Sounds like you should file an issue on DOMDuture because this is not how
it currently works.

/ Jonas