Re: Concerns about DOMRequest

On 15/02/13 15:51, Wonsuk Lee wrote:
> Hi. Mounir.
> 
> 2013. 2. 16. 오전 12:22 Mounir Lamouri <mounir@lamouri.fr> 작성:
> 
>> 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.
> 
> For clear understanding, could you show up a example code using above WebIDL?

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.

However, we shouldn't spend too much time debating that. My point is
just that DOMRequest vs DOMFuture is not a discussion. One is just the
other with some additions, they have incompatibility except the naming
of some attributes and events.

I think we should discuss if DOM{Future,Promise} should have DOM events,
if we should just add a Future type in Javascript, etc.
But that discussion should probably happen outside of that group?

Cheers,
--
Mounir

Received on Friday, 15 February 2013 18:43:24 UTC