Re: Concerns about DOMRequest

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.

/ Jonas

Received on Wednesday, 20 February 2013 01:07:43 UTC