Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.straub-nv.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <1603326.gHQpjbgioL@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Mon, 07 Jan 2013 04:36:24 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit Subject: Re: Two versions of code - advantages and differences Newsgroups: comp.lang.javascript References: <1512443.gQHv90F1im@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 168 NNTP-Posting-Date: 07 Jan 2013 04:36:25 CET NNTP-Posting-Host: 52bab398.newsspool1.arcor-online.net X-Trace: DXC=11llL`bU9=C@Y=h<_c3PkHic==]BZ:afN4Fo<]lROoRAnkgeX?EC@@@59mb1gI=;^IDZm8W4\YJNLb@mF9jNikdEWWB88 W dniu 2013-01-04 15:31, Thomas 'PointedEars' Lahn pisze: >> Cezary Tomczyk wrote: >>> I have a two versions of code. They are just only examples and contains >>> simple operations, but I want to understand more deeply some general >>> things. >>> >>> Version 1 >>> >>> var el = document.getElementById('test'); >>> var fn = function(){ >>> if( !el ){ >>> // fallback if el is not available and then return >>> } >>> return el; >>> }; >>> >>> Version 2 >>> >>> var fn = (function(){ >>> var el = document.getElementById('test'); >>> >>> if(el){ >>> return function(){ >>> return el; >>> } >>> } else { >>> // fallback if el is not available and then return >>> } >>> }()); >> >> […] >>> […] >>> Anything else what can be said about advantages or differences between >>> them? >> >> Static code analysis has a hard(er) time recognizing that “fn” actually >> refers to a function in Version 2. AFAIK, the JSDoc Toolkit cannot deal >> with it at all (but my JSdoc is going to). > > True, but they are two different examples. Your point being? >> Another advantage of Version 1 over Version 2 is that it does not matter >> if “el” is initialized, or its initialization value is available, before ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> or after the definition. For example, you would not want to use Version ^^^^^^^^^^^^^^^^^^^^^^^ >> 2 in a library that is loaded before the document has been loaded, >> because ”el” will be a false-value then. The document need not have been >> parsed to after the element in question, and the document tree not been >> populated as much, before the document has been loaded. If you skip the >> initialization of “el” in Version 1, you can load the code and still >> initialize “el” later, when appropriate. > > Yes, but the examples are really simple and I wanted to demonstrate some > general idea. The "el" doesn't have to be always an reference to object. > This could be anything and could be more complex. I was pointing out a general problem with self-calling functions, using an example. > I've just wrote something like this: > > var main = { > [...] > > apply : (function(){ > var tempImg = document.createElement('img'), > t, img; > tempImg.width = '10'; > tempImg.height = '10'; > > return function(o){ > img = tempImg.cloneNode(false); > img.alt = o.alt; > img.src = o.src; > t = document.createElement('span'); > t.appendChild(document.createTextNode('\u00a0')); > t.appendChild(img); > t.appendChild(document.createTextNode('\u00a0')); > window.setTimeout(function(){ examplefn(t); }, 100); > }; > } ^^ JFYI: This is not going to work. > [...] > }; > > As I understand (correct me if I am wrong) this is inefficient because: > > * closure need extra memory and will be always in memory because > returned function refers to variables that are outside of returned > function. > > * "apply" is parsed immediately which is not needed always > > Anything else inefficient or wrong? Your code does not make sense to me at all, regardless of possible inefficiencies. You are creating on initialization an ”img” object only to clone it non-recursively (assuming this works) when the returned function is called only to skip the “width” and “height” assignment – seriously? I would have written apply: function (o) { var img = document.createElement('img'); img.width = 10; img.height = 10; img.alt = o.alt; img.src = o.src; var t = document.createElement('span'); t.appendChild(document.createTextNode('\u00a0')); t.appendChild(img); t.appendChild(document.createTextNode('\u00a0')); window.setTimeout(function() { examplefn(t); }, 100); } here, and further optimized (with regard to maintenance effort and compatibility) to apply: (function () { var _createElementFromObj = jsx.dom.createElementFromObj; var _runAsync = jsx.dom.timeout.runAsync; return function (o) { var t = _createElementFromObj({ type: "span", childNodes: [ "\u00a0", { type: "img", properties: { width: 10, height: 10, alt: o.alt, src: o.src } }, "\u00a0" ] }); _runAsync(function () { examplefn(t); }, 100); }; }()) (Wrappers like that are functionally optional of course, but I find them very useful. Although it escapes me here why you would want to insert the equivalent of “ ” before and after the image; this should be done with the “margin” CSS property instead.) There are times when extra closures are a good idea, and there are times when they are not. There is no definitive answer here, but my code should give you some idea. -- PointedEars Twitter: @PointedEars2 Please do not Cc: me. / Bitte keine Kopien per E-Mail.