Re: Concerns about DOMRequest

On 15/02/13 07:22, Marcos Caceres wrote:
> On Friday, 15 February 2013 at 05:08, Jonas Sicking wrote:
> 
>> On Thu, Feb 14, 2013 at 4:35 AM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
>>>
>>>
>>>
>>> On Thursday, 14 February 2013 at 11:17, Anne van Kesteren wrote:
>>>
>>>> On Wed, Feb 13, 2013 at 8:27 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
>>>>> It would still really suck if you added .then() but still required everything to be wrapped in a function.
>>>>
>>>>
>>>>
>>>> What do you mean by this?
>>>
>>> In IDB, the design of the API forces a developer to do everything synchronously, even though the IDB operation is async in the background (you have to start an operation before you can set listeners on it - so developer are forced to do everything in one go inside a function). See the following, for example:
>>> http://www.html5rocks.com/en/tutorials/indexeddb/todo/#toc-step2
>>
>> This is simply not accurate. DOMRequest doesn't force you to do
>> anything synchronously that DOMFuture/Promises doesn't.
> 
> Right, it might be either designs not appropriate for the given use cases and APIs. Also, my statement holds in that I was not comparing it to DOMFuture or whatever. You still can't use the DOMRequest pattern in a JS console, for instance, because the way the APIs that rely on it are designed.

>> As you can see, the .then function on DOMFuture/Promises certainly
>> makes the code cleaner and removes a lot of the syntax overhead. But
>> the capabilities are exactly the same.
> 
> Cleaner code is good.  

>> This is not to say that the .then function isn't important. It makes a
>> huge difference. But if you have other problems with DOMRequest then
>> those concerns likely applies to DOMFuture as well.
>>
> 
> It may be that both are inappropriate for any particular API. What I'm advocating is not one over the other, but that each API be looked at independently and we use what is most appropriate (DOMRequest, DOMFuture, simple callbacks, an "intent", something new, whatever). My concern is that DOMRequest was being used on "all the things" as some kind of magic bullet:
> 
> "DOMRequest intend to be used instead of those callbacks to make those APIs more developer-friendly and help code readability." - [1][2]
>  
> As you just proved by comparing to DOMFuture, the above statement is wildly inaccurate and misleading. I'm asking that all the text about DOMRequest be removed from the Runtime document and that we assess the applicability of what is most appropriate on a case by case basis.

You are assuming that DOMRequest can't do that by design. Adding the
following WebIDL would fix DOMRequest to have the same syntax sugar as
DOMFuture:

Callback RequestCallback = any (any aValue);

partial interface DOMRequest {
  DOMRequest then(RequestCallback successCallback, RequestCallback
errorCallback);
};

It's been in our plans for months to improve DOMRequest to have a
future-like design, this is why the specification is phrased like this.

--
Mounir

Received on Friday, 15 February 2013 15:23:04 UTC