Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail
From: Cezary Tomczyk <cezary.tomczyk@gmail.com>
Newsgroups: comp.lang.javascript
Subject: Re: Two versions of code - advantages and differences
Date: Sun, 06 Jan 2013 22:30:08 +0100
Organization: Aioe.org NNTP Server
Lines: 114
Message-ID: <kccqct$ksk$1@speranza.aioe.org>
References: <kc4uud$fam$1@speranza.aioe.org> <1512443.gQHv90F1im@PointedEars.de>
NNTP-Posting-Host: RMrsF+s1qSnxq5Qkkqjnpw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.javascript:17989

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
>>       }
>> }());
>
> Your indentation looks partially bad here.  Use spaces, not tabs.

Sorry, copied and pasted from Aptana maybe was wrong.

>> […]
>> 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.

> 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.

> Your should not simply return in the second branch in Version 2, because
> calls will fail then; you should return a reference to a Function instance
> with an empty function body.  Incidentally, this code can then be simplified
> to
>
>    var fn = (function () {
>      var el = document.getElementById('test');
>
>      return function () {
>        return el;
>      };
>    }());
>
> where it becomes obvious that the additional closure is not really needed
> here, and the function itself is unnecessary.  Perhaps you should present
> better examples.

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);
         };
     }

     [...]
};

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?

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/