Re: Concerns about DOMRequest

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), having two attributes sounds better. We could
have .result returning a DOMError if the request failed but it seems
tricky because that prevents the DOMRequest to actually return a
DOMError for non-failing situations. Otherwise, we have to request the
user to always know the context to understand what is the meaning of
.result (ie. if .result returns a DOMError in a success context, that
means the DOMError is the expected result). This is also a solution and
one can argue that the API consumer very likely knows the context (this
being called from a success/error handler).

However, I wouldn't consider that as an absurd thing that makes the API
crappy. It seems more like a matter of POV/taste.

> Also, these APIs and JavaScript as it they are won't support promise
> chainability and the excellent error forwarding that comes with it
> off-the-shelf. Also, the lack of a built-in Q.all really doesn't promote
> good code when it comes to event synchronization.
> Oh yes, of course, you can always build a promise library on top of the
> current APIs, blablabla... and waste battery with these libraries [3].

All of those concerns can clearly be fixed without changing the current API.

--
Mounir

Received on Monday, 18 February 2013 15:36:24 UTC