- From: David Bruant <bruant.d@gmail.com>
- Date: Wed, 08 May 2013 19:05:10 +0100
- 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