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

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 29 Jan 2013 15:58:28 -0800
Message-ID: <CABZUbM0n-C9u8juPH=cuDwJFqpSajbrbMYVSSJ=TtVPJm90DUQ@mail.gmail.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 1/29/13, Elliott Sprehn <esprehn@gmail.com> wrote:
> 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".
>
Idiomatically.  That's the only reason for constructors. And even
there, they can be replaced by 'create' type methods.

When constructor is undesirable or inelegant, then the API can hide
the details of the construction and be designed with a function. For
example:-

var callbacks = {
  load : function(){},
  abort : function() {},
  timeout : function() {}
};

makeHttpReq( url, callbacks );

In the case of the HTTP Request API, could it not have been specified
in this manner, and for a codified standard, exposed the
XMLHttpRequest constructor?

 var a = new Image();
 a.onload = f1;
 a.onerror = f2;
 downloadImage(src);

On the case of Notifications, it seems that the argument is not if
there is a use case, but about the semantics for realizing it. What do
you think?
-- 
Garrett
Twitter: @xkit
Received on Tuesday, 29 January 2013 23:58:53 GMT

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