- From: Elliott Sprehn <esprehn@gmail.com>
- Date: Tue, 29 Jan 2013 13:26:28 -0500
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: Charles McCathie Nevile <chaals@yandex-team.ru>, olli@pettay.fi, WHATWG <whatwg@whatwg.org>
On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald <jaffathecake@gmail.com>wrote: > On 29 January 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(). It also lets you create clean abstractions and layers so one library may create the notification, but another one may eventually show it. With notifications I can't look at the properties of a notification in the web inspector without having it show on me... Constructors are not verbs. new Notification doesn't mean "show", and new XMLHttpRequest doesn't mean "send". This is pretty standard OO best practices stuff. ex. http://www.beaconhill.com/solutions/kb/java/code-in-constructor-anti-pattern.html - E
Received on Tuesday, 29 January 2013 18:27:33 UTC