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

Ryosuke Niwa rniwa at apple.com
Tue Jan 29 12:02:23 PST 2013

On Jan 29, 2013, at 10:26 AM, Elliott Sprehn <esprehn at gmail.com> wrote:

> On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald <jaffathecake at gmail.com>wrote:
>> On 29 JanuaJake Archibald <jaffathecake at gmail.com>ry 2013 05:36, Charles McCathie Nevile <chaals at 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

More information about the whatwg mailing list