Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #17926

Re: Source code "objectifying" technique?

Show all headers | View raw

On 2013-01-03 21:13, JJ wrote:
> Stefan Weiss <krewecherl@gmail.com> wrote:
>> Not every collection of functions can be contained in this way, but it
>> should work for your typical bunch-of-global-functions-because-
>> -the-author-doesn't-know-any-better library.
> 
> Like bound functions?

Bound as in Function.prototype.bind? Maybe. Off the top of my head, I
can't think of how that would cause problems, if what the functions are
bound to is also in the scope of the anonymous closure.
I was thinking more of libraries directly setting properties on the
global object, or missing variable declarations.

> Also, do this two conversions have any functionality difference? Or may 
> be leads to possible error elsewhere?
> 
> //original
> function abc(){}
> //conversion #1
> theLib.abc=function abc(){};
> //conversion #2
> theLib.abc=function(){};

Conversion #2 has the potential to cause problems in JScript, because of
the braindead way IE handles named function expressions:

http://kangax.github.com/nfe/#jscript-bugs

This is why I generally avoid NFEs. I still want most functions to have
a name, because it makes debugging so much easier in large applications.
As a result, I often prefer function declarations over function
expressions, even if it requires the "return {...API...}" bit at the and
of a "module", like in the example from my previous post.

I do use function expressions a lot, but when I find myself writing code
like this -

    button.addEventListener("click", function (evt) {
        // 10 lines of code
        connection.post(url, params, function (resp) {
            // and maybe another nested function...
        });
    });

- I tend to refactor it into something simpler:

   button.addEventListener("click", handleClick);

   function handleClick (evt) {
        // 10 lines of code
        connection.post(url, params, receiveResponse);
   }

   function receiveResponse (resp) {
       // and maybe another nested function...
   }

This will give all functions a name, making debugging, documenting, and
visually scanning the code easier. It also keeps the function bodies
short and avoids the typical >-shape of highly nested functions
(callback hell).

All of that is just my personal preferred style, not a general
recommendation, but it has served me well over the years.


- stefan

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Source code "objectifying" technique? JJ <jaejunks@nah.meh> - 2013-01-03 10:34 +0000
  Re: Source code "objectifying" technique? Stefan Weiss <krewecherl@gmail.com> - 2013-01-03 19:32 +0100
    Re: Source code "objectifying" technique? JJ <jaejunks@nah.meh> - 2013-01-03 20:13 +0000
      Re: Source code "objectifying" technique? Stefan Weiss <krewecherl@gmail.com> - 2013-01-03 23:57 +0100
        Re: Source code "objectifying" technique? Stefan Weiss <krewecherl@gmail.com> - 2013-01-04 00:44 +0100
        Re: Source code "objectifying" technique? JJ <jaejunks@nah.meh> - 2013-01-04 02:00 +0000
  Re: Source code "objectifying" technique? Scott Sauyet <scott.sauyet@gmail.com> - 2013-01-03 10:37 -0800
    Re: Source code "objectifying" technique? Scott Sauyet <scott.sauyet@gmail.com> - 2013-01-03 10:43 -0800
    Re: Source code "objectifying" technique? JJ <jaejunks@nah.meh> - 2013-01-03 20:33 +0000
      Re: Source code "objectifying" technique? Scott Sauyet <scott.sauyet@gmail.com> - 2013-01-03 13:09 -0800
        Re: Source code "objectifying" technique? JJ <jaejunks@nah.meh> - 2013-01-04 02:33 +0000

csiph-web