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

[Garrett Smith]

On 1/29/13, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Ryosuke Niwa wrote:
>>On Jan 29, 2013, at 10:26 AM, Elliott Sprehn <esprehn at gmail.com> wrote:
>>> 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.
>
I think not.

I can make an email "response", hang onto it, and consider sending it
out tomorrow. Programmatically speaking, it holds to. That figurative
"callback" might be "email review done" and the handling of that would
be to "send" it.

For example, Java's ServletResponse is designed so that one can be
used and then other things done with it (request dispatcher, filter
chains, etc) before (or if) it is sent.

But that seems to be straying slightly off topic.

> `XMLHttpRequest` tries to encapsulate request, response, user agent, XML
> parser, and other things into a single object; that's rather dubious in-
> deed, but not the calling code's fault. A more typical object design is
> the separation I've just mentioned, in Perl for instance you would use a
> LWP::UserAgent object where you might set user agent properties like the
> User-Agent header or whether the user agent should follow redirects au-
> tomatically, and then use that object for many requests. You might pass
> it even to other objects in case they need to make any requests on your
> code's behalf; and if they don't need to after all, it's quite normal to
> dispose of the object without having made any requests.

Ah, API design.

Passing in an object to construct another object is common in
Javascript, too. Moreso for program code than W3C APIs -- but that can
change. I made the example for how XMLHttpRequest could have been
designed and indeed there are libraries that use such approach.

The Notifications API seems to have room for improvement. I'm not
discounting the case it fills, but the OP had a good point about the
API design itself.

Who is intimately familiar with that API can produce a nicer API
design that addresses the side effects and usage pattern?
-- 
Garrett
Twitter: @xkit
personx.tumblr.com