Re: Concerns about DOMRequest

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

David

[1] https://twitter.com/DavidBruant/status/302891182323814401

Received on Tuesday, 19 February 2013 22:07:55 UTC