Re: [whatwg] [Notifications] Constructor should not have side effects
On Mon, Jan 28, 2013 at 11:41 PM, Olli Pettay olli.pet...@helsinki.fi wrote: WebSocket, EventSource etc ctors do have side effects. Exactly. And if we designed XMLHttpRequest from scratch it would have them too. -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, 29 Jan 2013 11:28:01 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jan 28, 2013 at 11:41 PM, Olli Pettay olli.pet...@helsinki.fi wrote: WebSocket, EventSource etc ctors do have side effects. 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? cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, Jan 29, 2013 at 7:36 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Really? This doesn't seem like a good idea, so I'd be interested to know why. Is there an explanation laid out somewhere? Just to ask from another perspective: why doesn't it seem like a good idea? Having objects that begin their job when constructed simply avoids an extra step for the user (telling it to start), and reduces the number of possible states (eg. eliminating the UNSENT state), which generally simplifies things. Supporting reuse of objects is generally not a useful optimization (in my experience), so not supporting it also simplifies things a bit. Reducing the number of different-but-equivalent ways of doing the same thing is also generally good API design. -- Glenn Maynard
Re: [whatwg] [Notifications] Constructor should not have side effects
Glenn Maynard gl...@zewt.org wrote: On Tue, Jan 29, 2013 at 7:36 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Really? This doesn't seem like a good idea, so I'd be interested to know why. Is there an explanation laid out somewhere? Just to ask from another perspective: why doesn't it seem like a good idea? All the information required to activate the object may not be available at the point at which the object is constructed. For example, how can you add event listeners to something that doesn't exist yet? Particularly if you want to use a closure with the new object. Having objects that begin their job when constructed simply avoids an extra step for the user (telling it to start), and reduces the number of possible states (eg. eliminating the UNSENT state), which generally simplifies things. Supporting reuse of objects is generally not a useful optimization (in my experience), so not supporting it also simplifies things a bit. Reducing the number of different-but-equivalent ways of doing the same thing is also generally good API design. I agree - but I don't see what this has to do with separating construction from activation. -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald jaffathec...@gmail.comwrote: On 29 January 2013 05:36, Charles McCathie Nevile cha...@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. ex. http://www.beaconhill.com/solutions/kb/java/code-in-constructor-anti-pattern.html - E
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, 29 Jan 2013, Elliott Sprehn wrote: On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald wrote: 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. As a JS author you really shouldn't be worrying about pre-allocating stuff. Let the browser decide how to optimise for that. The browser is in a better position to know whether it's better to optimise for memory usage, creating objects at the last minute, or whether it's better to optimise for speed, with objects pre-created and ready to roll when the script invokes them. It's possible that objects like this will be hosted in a pre-allocated arena, where the construction cost is essentially free, so that there's no advantage to doing it ahead of time in the JS. It's also possible that the system is seriously memory-constrained, so that the allocation should only be done if it is absolutely necessary. It's possible that the browser isn't really going to allocate anything at all because it has a highly-optimised primitive for this type of object, so that changing the object from undefined to a constructed WebSocket object will require no more than changing a few bits in the underlying value (e.g. because the networking layer doesn't hold much state for these objects, and therefore holds it all in a pre-allocated data structure which the JS interpreter just needs to index into). With notifications I can't look at the properties of a notification in the web inspector without having it show on me... What properties would you want to look at? 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. ex. http://www.beaconhill.com/solutions/kb/java/code-in-constructor-anti-pattern.html That post asserts this, but provides no reasoning for it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Notifications] Constructor should not have side effects
On Jan 29, 2013, at 10:26 AM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald jaffathec...@gmail.comwrote: On 29 JanuaJake Archibald jaffathec...@gmail.comry 2013 05:36, Charles McCathie Nevile cha...@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
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, 29 Jan 2013, Ryosuke Niwa wrote: 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? This is easy to do. Just return a function that creates the notification, instead of returning a non-shown notification object. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa rn...@apple.com wrote: ... Is that even a valid use case? It seems dubious to instantiate a class named request and then not send a request. You can't go down that line of thinking because it doesn't generalize. For instance why would I instantiate a class named node without putting it into the tree? If we followed that logic then new HTMLDivElement should append itself into the document by default. - E
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, 29 Jan 2013, Elliott Sprehn wrote: On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa rn...@apple.com wrote: ... Is that even a valid use case? It seems dubious to instantiate a class named request and then not send a request. You can't go down that line of thinking because it doesn't generalize. For instance why would I instantiate a class named node without putting it into the tree? There are all kinds of reasons why you may do this. Hence, we support it. Reasoning by use case definitely generalises -- it's how we design everything around here. :-) If we followed that logic then new HTMLDivElement should append itself into the document by default. A more apt example would be the way audio, when constructed with a URL, immediately starts loading it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Notifications] Constructor should not have side effects
On Tue, Jan 29, 2013 at 3:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 29 Jan 2013, Elliott Sprehn wrote: On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa rn...@apple.com wrote: ... Is that even a valid use case? It seems dubious to instantiate a class named request and then not send a request. You can't go down that line of thinking because it doesn't generalize. For instance why would I instantiate a class named node without putting it into the tree? There are all kinds of reasons why you may do this. Hence, we support it. Reasoning by use case definitely generalises -- it's how we design everything around here. :-) But reasoning by naming certainly doesn't. His comment was about creating a class named request.
Re: [whatwg] [Notifications] Constructor should not have side effects
On Jan 29, 2013, at 12:41 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Jan 29, 2013 at 3:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 29 Jan 2013, Elliott Sprehn wrote: On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa rn...@apple.com wrote: ... Is that even a valid use case? It seems dubious to instantiate a class named request and then not send a request. You can't go down that line of thinking because it doesn't generalize. For instance why would I instantiate a class named node without putting it into the tree? There are all kinds of reasons why you may do this. Hence, we support it. Reasoning by use case definitely generalises -- it's how we design everything around here. :-) But reasoning by naming certainly doesn't. His comment was about creating a class named request. Sorry, I think you misunderstood me. I didn't mean that literally. - R. Niwa
Re: [whatwg] [Notifications] Constructor should not have side effects
On 1/29/13, Elliott Sprehn espr...@gmail.com wrote:
On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald
jaffathec...@gmail.comwrote:
On 29 January 2013 05:36, Charles McCathie Nevile cha...@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
Re: [whatwg] [Notifications] Constructor should not have side effects
On Jan 29, 2013 12:07 PM, Stewart Brodie stewart.bro...@antplc.com wrote: For example, how can you add event listeners to something that doesn't exist yet? Particularly if you want to use a closure with the new object. The same way as always: just attach the listener. You can't miss events, since it's guaranteed that no events will be fired before returning to the event loop. This is a universal idiom on the platform, FYI. Having objects that begin their job when constructed simply avoids an extra step for the user (telling it to start), and reduces the number of possible states (eg. eliminating the UNSENT state), which generally simplifies things. Supporting reuse of objects is generally not a useful optimization (in my experience), so not supporting it also simplifies things a bit. Reducing the number of different-but-equivalent ways of doing the same thing is also generally good API design. I agree - but I don't see what this has to do with separating construction from activation. Object reuse was given as an argument to having a separate send() method, but allowing object reuse is a bad thing unless there are compelling use cases for supporting it. On Tue, Jan 29, 2013 at 12:26 PM, Elliott Sprehn espr...@gmail.com wrote: With notifications I can't look at the properties of a notification in the web inspector without having it show on me... It doesn't matter if it's being shown or not, if you're just debugging. Constructors are not verbs. new Notification doesn't mean show, and new XMLHttpRequest doesn't mean send. I disagree. This is pretty standard OO best practices stuff. I disagree. Unless you give arguments rather than assertions, there's nothing to argue against, so all I can do is state my disagreement. Constructors are essentially nothing but a different syntax for a function that returns an object of the same type. Some languages, like Python, don't even differentiate the syntax. There's no implication about side-effects one way or the other. -- Glenn Maynard
Re: [whatwg] [Notifications] Constructor should not have side effects
* Ryosuke Niwa wrote: On Jan 29, 2013, at 10:26 AM, Elliott Sprehn espr...@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. `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. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] [Notifications] Constructor should not have side effects
On 1/29/13, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Ryosuke Niwa wrote: On Jan 29, 2013, at 10:26 AM, Elliott Sprehn espr...@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
Re: [whatwg] [Notifications] Constructor should not have side effects
On 01/29/2013 12:15 AM, Elliott Sprehn wrote: The Notification constructor should not have side effects. This is generally considered bad design, and the rest of the platform doesn't have this either. Specifically new Notification() should not show the notification since it prevents reuse of the notification after calling close(), and is surprising behavior. (ex. new XMLHttpRequest doesn't fire the request, new HTMLDivElement() shouldn't append it to the document, ...) WebSocket, EventSource etc ctors do have side effects. It feels natural to me that Notification is one time object. Once you've used it, you just create a new one if needed. Also, it is probably too late to change Notification API. -Olli
