- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Tue, 29 Jan 2013 12:02:23 -0800
- To: Elliott Sprehn <esprehn@gmail.com>
- Cc: Charles McCathie Nevile <chaals@yandex-team.ru>, olli@pettay.fi, Jake Archibald <jaffathecake@gmail.com>, WHATWG <whatwg@whatwg.org>
On Jan 29, 2013, at 10:26 AM, Elliott Sprehn <esprehn@gmail.com> wrote: > On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald <jaffathecake@gmail.com>wrote: > >> On 29 JanuaJake Archibald <jaffathecake@gmail.com>ry 2013 05:36, Charles McCathie Nevile <chaals@yandex-team.ru> >> wrote: >>>> Exactly. And if we designed XMLHttpRequest from scratch it would have >> them >>>> too. >>> >>> Really? This doesn't seem like a good idea, so I'd be interested to know >>> why. Is there an explanation laid out somewhere? >> >> Why doesn't it seem like a good idea? Is there a use-case for creating >> a Notification/XMLHttpRequest/WebSocket/EventSource without performing >> their action? > > Yes, because decoupling allocating from action lets you preallocate objects > to perform a task in advance of executing the task. It lets you structure > your code without having to worry about when something executes, and it > lets you inspect the object in the web inspector without having the verb > execute first. > > For example you can do var request = new XMLHttp( .... ) at the start of a > function, but then later decide you didn't want to send the request, and > never call send(). Is that even a valid use case? It seems dubious to instantiate a class named "request" and then not send a request. > It also lets you create clean abstractions and layers so > one library may create the notification, but another one may eventually > show it. This seems like a valid concern. Do existing libraries do this with XHR and other objects that separate primary actions from instantiations? - R. Niwa
Received on Tuesday, 29 January 2013 20:02:50 UTC