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

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

From: Elliott Sprehn <esprehn@gmail.com>
Date: Tue, 29 Jan 2013 13:26:28 -0500
Message-ID: <CAPJYB1jwhi074AUhWVgV9q1QL_PG7DXFF5BLguZM4XEkZgCbRA@mail.gmail.com>
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.

- E
Received on Tuesday, 29 January 2013 18:27:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:52 UTC