- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 12 Apr 2013 18:02:29 +0100
- To: Elliott Sprehn <esprehn@gmail.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-webapps <public-webapps@w3.org>
On Fri, Apr 12, 2013 at 11:43 AM, Elliott Sprehn <esprehn@gmail.com> wrote: > Sure they do, they allow future extensibility. If we had used Futures for > everything from the start the world would be quite different since we > couldn't add any new information to the notifications. I can't think of many APIs we extended in this fashion over the years I have to say. The MessageEvent interfaces comes to mind, but that already had more than one member from the start. (FWIW, in the particular case of requestFullscreen() I agree that we need to keep the event, non-the-least because it dispatches across documents. But the result of the call itself, including the error notification, might be better as a future.) > All the Future<boolean> stuff going on right now is just going to bite us > later when we want to add more features to some notification. The proposals are Future<...> and I suspect in most cases "..." will be something that does allow more to be exposed over time. > For example requestAnimationFrame _could_ be a Future<int> since it's only > called once, but now we want to pass a bunch of information into from the > compositor but can't since there's no extensibility mechanism. Given that this operation cannot fail, I'm not sure futures are the right abstraction. If they were, you'd think in advance about whether you might want to expose more data or not and resolve the future with an object that holds the value. > What's the long term evolution plan for all this? How do we extend the APIs > in the future since we don't have an Event object to add properties to? See above, I'm not sure we've actually had the need for this often. -- http://annevankesteren.nl/
Received on Friday, 12 April 2013 17:02:56 UTC