W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [Future] reject() value type

From: David Bruant <bruant.d@gmail.com>
Date: Wed, 08 May 2013 19:05:10 +0100
Message-ID: <518A93D6.6030707@gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: Mounir Lamouri <mounir@lamouri.fr>, "www-dom@w3.org" <www-dom@w3.org>
Le 08/05/2013 18:52, Domenic Denicola a écrit :
> I think the less constraining approach is reasonable, although I question whether you'd need much extra beyond just a general agreement that all DOM specs use DOMError as their rejection reason. Stated another way, I think if you implemented the `Future<TValue, TReason>` idea, all DOM specs would just end up doing `Future<TValue, DOMError>`, which seems kind of pointless.
Future<T> can be a shorthand for Future<T, DOMError>. The 2-param 
genericity can make sense if others define their API through WebIDL.

For a bit more context, the Future<T, DOMError> notation emerged of 
thinking about what types could be used as a .reject argument because 
how the value is used in the .catch depends on what type it is. And this 
kind of thing is usually part of the documentation; explaining the 
contract of a method. So this WebIDL notation is just a way to make 
explicit that the possibility is offered to people writing JS API. 
Whether it's encouraged or a good practice is a different topic, but 
there is no strong reason to fully prevent it I believe.

David
Received on Wednesday, 8 May 2013 18:05:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC