- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 17 Apr 2013 08:45:01 -0700
- To: Norbert Lindenberg <w3@norbertlindenberg.com>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "public-script-coord@w3.org" <public-script-coord@w3.org>, public-rdf-comments <public-rdf-comments@w3.org>
On Wed, Apr 17, 2013 at 7:24 AM, Norbert Lindenberg <w3@norbertlindenberg.com> wrote: > On Apr 16, 2013, at 16:55 , Tab Atkins Jr. wrote: > >> On Tue, Apr 16, 2013 at 8:30 AM, Markus Lanthaler >> <markus.lanthaler@gmx.net> wrote: >>> After a short discussion with Robin we decided to use method overloading to > >>> We also considered Futures but decided that introducing a normative >>> dependency to the DOM spec is not acceptable at this stage. > >> In this case, your API is a textbook example of Futures. You have an >> async call which returns a single value, or an error. You can't get >> much more perfect than that. > > Maybe Futures should be in a separate spec? They don't seem to have any dependencies on DOM, and having them separate would reduce the bureaucratic hurdles for non-DOM specs to refer to them. Maybe eventually they could migrate into the ECMAScript standard library (currently known as ES chapter 15). I suspect that baking them into JS would be a great final destination. In the meantime, though, that doesn't help the stated bureaucratic hurdles, because a separate "Futures" spec will be exactly as standards-track-advanced as the current DOM spec. ~TJ
Received on Wednesday, 17 April 2013 15:45:51 UTC