Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsreader4.netcologne.de!news.netcologne.de!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <2999240.SPkdTlGXAF@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Fri, 04 Nov 2011 20:44:19 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit Subject: Re: calling function within (function() {...})(); Newsgroups: comp.lang.javascript References: <8928443.SEqChMirdb@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 79 NNTP-Posting-Date: 04 Nov 2011 20:44:19 CET NNTP-Posting-Host: e1dd091d.newsspool4.arcor-online.net X-Trace: DXC=C_XeDZm8W4\YJNl;?f@h5gMfblIdjL;PkV Thomas 'PointedEars' Lahn writes: >> Eric Bednarz wrote: >>> Gregor Kofler writes: >>>> Am 2011-11-04 13:18, Andrew Poulos meinte: >>>>> var x = (function(){ >>>>> return { >>>>> a : function(){}, >>>>> b : function(){} >>>>> }; >>>>> })(); >>> >>> var x = (function () { >>> function a() { >>> b(); >>> } >>> function b() { >>> >>> } >>> return { >>> a: a, >>> b: b >>> }; >>> }()); >> >> There is no inherent advantage in that. In fact, it is slightly less >> efficient than the original code because the `a' and `b' identifiers need >> to be resolved first, > > If a, b[, n] are used a lot in a context where they need not be methods > of an object, it would seem futile (and – depending on the number of > calls – quite inefficient) to me to call them as methods of an object > nevertheless. The sole purpose of this code is to return a reference to a newly created object and assign that reference to `x'. By contrast to a simple Object literal, though, this pattern provides the possibility of "private properties" (local variables of the created execution context) that can only be accessed from the object's initial methods through the closure. You have provided code that adds no inherent value to that but, in addition to the drawbacks already mentioned, in `b', which is called by the a() method of the object, `this' does not refer to that object. I fail to see the logic in that. You might also want to take note of the fact that at least one object is always involved when a function is called in an ECMAScript implementation. >>> window.setTimeout(x.a, 0); >> >> window.setTimeout(function() { x.a(); }, 10); > > You don’t say (I suppose creating a superfluous function object is > justified by not resolving those pesky identifiers first :^) The Function instance is not superfluous. If you do not use the function expression here, then only the reference to `x.a' will be called, which means that `x.a' will be called as a method of the object that `window' refers to, or if you will, the global object. As a result, `this' in `x.a' would not refer to the same object as `x', but to the other object. We have been over this ad nauseam. >> The asynchronous call is unnecessary here, though. > > That’s the problem of all artificial example code. In the origignal > code, calling a function expression that does nothing but returning an > object was unnecessary, too. Your logic is flawed. *You* have introduced the unnecessary asynchronous call for no good reason. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from (404-comp.)