W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] [Notifications] Constructor should not have side effects

From: Ryosuke Niwa <rniwa@apple.com>
Date: Tue, 29 Jan 2013 12:02:23 -0800
Message-id: <25B2D4EE-4214-49D3-8D8C-5B99D6D7E6D3@apple.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT