Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: Stefan Weiss on 20 May 2010 23:27 On 21/05/10 03:18, David Mark wrote: > dhtml wrote: >> On May 20, 5:50 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>> Andrea Giammarchi wrote: >>>> new expression is basically an "elegant" module pattern recognizable >>>> since the beginning. >>>> var o = (function () {}()); >>> Good, except the last parenthesis is in the wrong spot. Isn't that more a matter of preference? The outcome is the same in both cases. >>>> var o = new function () {}; >>>> what can "o" be in above case? Inevitably an object ;-) >>> Too bad it is the wrong answer. :) Don't use that. >> >> The only way it cannot be an object is if the function throws an >> error. > > That's not what I meant. I meant don't use that pattern. It's an awful > choice for a one-off. ISTM this was just discussed recently. This is really hard to search for in Google Groups (even if the search were working correctly). I don't remember this discussion. Could you recap why this pattern is bad? -- stefan
From: David Mark on 21 May 2010 02:47 Stefan Weiss wrote: > On 21/05/10 03:18, David Mark wrote: >> dhtml wrote: >>> On May 20, 5:50 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> Andrea Giammarchi wrote: >>>>> new expression is basically an "elegant" module pattern recognizable >>>>> since the beginning. >>>>> var o = (function () {}()); >>>> Good, except the last parenthesis is in the wrong spot. > > Isn't that more a matter of preference? > The outcome is the same in both cases. > >>>>> var o = new function () {}; >>>>> what can "o" be in above case? Inevitably an object ;-) >>>> Too bad it is the wrong answer. :) Don't use that. >>> The only way it cannot be an object is if the function throws an >>> error. >> That's not what I meant. I meant don't use that pattern. It's an awful >> choice for a one-off. ISTM this was just discussed recently. > > This is really hard to search for in Google Groups (even if the search > were working correctly). I don't remember this discussion. Could you > recap why this pattern is bad? > > I can't as I don't remember all of the views expressed. Personally, I see it as very poor taste. For one, as stated, it calls a constructor without the call operator. And it's not immediately apparent that the developer didn't make a mistake. Perhaps they meant:- var abc = function() { }; ....but got confused about the Function constructor. Certainly such an error should have been apparent on execution, but perhaps they also forgot to do anything with the result. I've seen it all. The larger the project, the more bizarre loose ends.
From: dhtml on 21 May 2010 04:19 On May 20, 11:47 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Stefan Weiss wrote: > > On 21/05/10 03:18, David Mark wrote: > >> dhtml wrote: > >>> On May 20, 5:50 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >>>> Andrea Giammarchi wrote: > >>>>> new expression is basically an "elegant" module pattern recognizable > >>>>> since the beginning. > >>>>> var o = (function () {}()); > >>>> Good, except the last parenthesis is in the wrong spot. > > > Isn't that more a matter of preference? > > The outcome is the same in both cases. > > >>>>> var o = new function () {}; > >>>>> what can "o" be in above case? Inevitably an object ;-) > >>>> Too bad it is the wrong answer. :) Don't use that. > >>> The only way it cannot be an object is if the function throws an > >>> error. > >> That's not what I meant. I meant don't use that pattern. It's an awful > >> choice for a one-off. ISTM this was just discussed recently. > > > This is really hard to search for in Google Groups (even if the search > > were working correctly). I don't remember this discussion. Could you > > recap why this pattern is bad? > > I can't as I don't remember all of the views expressed. Personally, I > see it as very poor taste. For one, as stated, it calls a constructor > without the call operator. And it's not immediately apparent that the > developer didn't make a mistake. Perhaps they meant:- > > var abc = function() { > > }; > > ...but got confused about the Function constructor. Certainly such an > error should have been apparent on execution, but perhaps they also > forgot to do anything with the result. I've seen it all. The larger > the project, the more bizarre loose ends. The Function constructor has nothing to do with this pattern at all. Misunderstanding the pattern is the mistake. The pattern itself is not The two approaches were provided without a problem context. Although they are similar to one another, strong conclusions of which is the better are hard to make without a context. Invoking an anonymous constructor is useful when your program wants an object whose methods have access to hidden methods (to hide implementation details). For example, an Animation Manager Registry. The Animation Manager Registry has a simple interface: register(animation) unregister(animation) The Animation Manager keeps track of how many animation objects it is managing in a list of animations. To preserve system resources, Animation Manager uses one setInterval and has its own callback function to run each Animation in the animationList. Using one setIntervale avoids performance degradation that would otherwise occur with multiple, concurrent (setTimeout or setInterval)s. When an Animation's time has expired, it is notified and subsequently removed. When a running Animation throws an error, the error is caught and the offending Animation is aborted immediately. Doing this prevents the error from being thrown repeatedly, as would happen otherwise. When the animationList becomes empty, the Animation Manager can clear the timer using clearInterval. When the Animation Manager's `register` method is called a timer is created, if that has not happened already. Is the pattern applicable here? The number of Animation Manager instances must be exactly one. The Animation Manager provides functionality that should not be exposed. Only the Animation Manager should be interested in whether or not it is in a running state or how that state is maintained, what the length of its animationList, etc. All of that is Animation Manager's private business. Certainly here, the pattern is not an awful choice.
From: Gregor Kofler on 21 May 2010 04:59 Am 2010-05-20 23:50, Andrea Giammarchi meinte: > new expression is basically an "elegant" module pattern recognizable > since the beginning. > > var o = (function () {}()); > > what can "o" be? just everything, included undefined. Why "everything, including undefinded"? It's just gonna be undefined. Gregor -- http://www.gregorkofler.com
From: David Mark on 21 May 2010 05:01
dhtml wrote: > On May 20, 11:47 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> Stefan Weiss wrote: >>> On 21/05/10 03:18, David Mark wrote: >>>> dhtml wrote: >>>>> On May 20, 5:50 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>>> Andrea Giammarchi wrote: >>>>>>> new expression is basically an "elegant" module pattern recognizable >>>>>>> since the beginning. >>>>>>> var o = (function () {}()); >>>>>> Good, except the last parenthesis is in the wrong spot. >>> Isn't that more a matter of preference? >>> The outcome is the same in both cases. >>>>>>> var o = new function () {}; >>>>>>> what can "o" be in above case? Inevitably an object ;-) >>>>>> Too bad it is the wrong answer. :) Don't use that. >>>>> The only way it cannot be an object is if the function throws an >>>>> error. >>>> That's not what I meant. I meant don't use that pattern. It's an awful >>>> choice for a one-off. ISTM this was just discussed recently. >>> This is really hard to search for in Google Groups (even if the search >>> were working correctly). I don't remember this discussion. Could you >>> recap why this pattern is bad? >> I can't as I don't remember all of the views expressed. Personally, I >> see it as very poor taste. For one, as stated, it calls a constructor >> without the call operator. And it's not immediately apparent that the >> developer didn't make a mistake. Perhaps they meant:- >> >> var abc = function() { >> >> }; >> >> ...but got confused about the Function constructor. Certainly such an >> error should have been apparent on execution, but perhaps they also >> forgot to do anything with the result. I've seen it all. The larger >> the project, the more bizarre loose ends. > > The Function constructor has nothing to do with this pattern at all. No kidding. :) But at a glance, a neophyte could get confused. You have to consider the _next_ guy. > Misunderstanding the pattern is the mistake. The pattern itself is not It's ugly. I say don't use it. > > The two approaches were provided without a problem context. Although > they are similar to one another, strong conclusions of which is the > better are hard to make without a context. Not for me. ;) > > Invoking an anonymous constructor is useful when your program wants an > object whose methods have access to hidden methods (to hide > implementation details). But that can be done in other ways (as we've discussed). > For example, an Animation Manager Registry. > The Animation Manager Registry has a simple interface: > > register(animation) > unregister(animation) Why would I need to register an animation? Right there you lost me. > > The Animation Manager keeps track of how many animation objects it is > managing in a list of animations. Huh? With My Library, you just point and shoot. > > To preserve system resources, Animation Manager uses one setInterval > and has its own callback function to run each Animation in the > animationList. Using one setInterval is different. Not necessarily a bad idea though. > Using one setIntervale avoids performance degradation > that would otherwise occur with multiple, concurrent (setTimeout or > setInterval)s. Yes. But at what cost in terms of the underlying code's complexity? > > When an Animation's time has expired, it is notified and subsequently > removed. Is that the (un)registration you spoke of? That casts a cloud over the whole thing IMO. API.showElement(el, true, { effects: [API.effects.spin, API.effects.fade[, ease: API.ease.cosine, duration: 1000 }); Similar options are available for setElementHtml, setElementNodes, changeImage, setScrollPosition, positionElement, sizeElement, updateElement, etc. But wait, there's more! Don't care to call tired old functions? Check out these OO examples*: E('myid').show(true, { effects: API.effects.flip, ease: API.ease.sine, duration: 500 }); E('myid').flipIn({ ease: API.ease.sine, duration: 500 }) E('myid').flipOut({ ease: API.ease.sine, duration: 500 }) Q('myclass').flipIn({ ease: API.ease.sine, duration: 500 }).removeClass('myclass').addClass('yourclass').addHtml('<p>Damn.</p>'); *Flip animation requires optional Transform add-on. This OO layer is also optional. The underlying API has no knowledge of it at all. So what could be more intuitive than that? And the examples write the code for you. http://www.cinsoft.net/mylib-examples.html But I digress. :) > > When a running Animation throws an error, the error is caught and the > offending Animation is aborted immediately. I don't care for that. Animations should not throw exceptions. And if they do, the developer needs to know about them sooner rather than later. > Doing this prevents the > error from being thrown repeatedly, as would happen otherwise. And how does that help anything? > When > the animationList becomes empty, the Animation Manager can clear the > timer using clearInterval. When the Animation Manager's `register` > method is called a timer is created, if that has not happened already. I really think you are barking up the wrong tree with that "register" stuff. Still, I suppose it is better than requiring a constructed throwaway object (like in Craptaculous). > > Is the pattern applicable here? > > The number of Animation Manager instances must be exactly one. There are no classes in JS. There's exactly one of everything. > The > Animation Manager provides functionality that should not be exposed. So use the pattern I recommended (as opposed to the one I panned). I really do know a bit about this stuff, you know? > > Only the Animation Manager should be interested in whether or not it > is in a running state or how that state is maintained, what the length > of its animationList, etc. All of that is Animation Manager's private > business. And none of that has anything to do with the topic at hand (which is choosing the right pattern). As mentioned (by the OP!) there is a perfectly suitable alternative. > > Certainly here, the pattern is not an awful choice. Yes, it is. You've missed the boat again. And I'm not turning it around. Let's just agree to "disagree" here. Fair enough? :) |