Self-Invoking Functions and PB

[James [a_leon]]

Dec 2, 2010 18:34:12 GMT -8 Jordan said:

Dec 2, 2010 11:15:05 GMT -8 Charles Stover said:

It would make sense if you wanted your variables private (it would be simpler and faster than an object), but in the event it doesn't matter (e.g. the "remove Welcome, X" ProBoards code; or variables that only contain basic information), there's no real reason to use it.

The only time I can imagine variables erroneously changing mid-code is when it runs on a timer, in which case you'd need a named function instead of a self-invoking one anyway.

Most scripts don't need private variables anyway, especially since most variables are never used again post-execution.

Especially when you figure that any code using the same variable name will be redefining it anyway.

It all works fine, I'm just saying that it's a good practice to have variable scope. I've had this kind of stuff pounded into my head at university so it just feels wrong to not do it.[/quote]

I agree for most things...but not javascript:P.

[Chris]

Contrary to what I'm reading here the reasons for use on a Proboards forum is even greater than another site where some form of collaborative effort is in place.

• Conflicts:
  JavaScript does use the event interrupt model so your code is not guaranteed exclusive use of execution time. A badly written event or timer can indeed preempt your code's execution and FUBAR any variables you may have defined which would naturally be global unless defined within the context of a function explicitly with the var keyword (1, 2) and that includes any functions you may have created in the global space for subsequent use. Besides being eco-friendly to the global system and protecting your code a self-invoker also protects other codes from yours. Think of how often win9x used to crashed when all applications were using shared memory then forward to the modern day NT architecture where context isolation of each process has drastically reduced BSODs. Take a peek in the code support board once-in-awhile and take note of the multitude of conflicts that could be prevented.
  
  
• Closure:
  By running in a separate context your code can take advantage of closure instead of relying on easily overwritten global variables. Closure is basically the ability of a function defined within the context of another function to access any variable defined in the parent function even when that parent function has completed and gone out of scope. This is ideal for defining event handlers when your main function does the one-time legwork of identifying any needed elements, values, etc. and your handler has complete access to them when invoked and no poorly written code can attack those values (1).
  
  

[Charles Stover]

Dec 3, 2010 5:53:43 GMT -8 Chris said:

Conflicts:
JavaScript does use the event interrupt model so your code is not guaranteed exclusive use of execution time. A badly written event or timer can indeed preempt your code's execution and FUBAR any variables you may have defined which would naturally be global unless defined within the context of a function explicitly with the var keyword (1, 2) and that includes any functions you may have created in the global space for subsequent use. Besides being eco-friendly to the global system and protecting your code a self-invoker also protects other codes from yours. Think of how often win9x used to crashed when all applications were using shared memory then forward to the modern day NT architecture where context isolation of each process has drastically reduced BSODs. Take a peek in the code support board once-in-awhile and take note of the multitude of conflicts that could be prevented.

Self-invoking functions wouldn't stop those conflicts. Proper code would. As mentioned before, code conflicts are due to referencing a variable in the future (e.g. on a timer) that may have changed as a result of another code. If the code is executed on a timer, the function will need to be named anyway, not self-invoked. If the function is named (thus already exists as a functions, as opposed to functionless codes we're already discussing), the programmer is perfectly capable of defining that function's variables locally instead of globally. If their code conflicts, they defined their variables globally, and a self-invoked function wouldn't change that.
The only other alternative would be that they didn't adequately define their variables in a way as not to allow other codes to interfere with them - they just threw around the variable x without considering that they didn't necessarily personally define it.

[Chris]

Dec 4, 2010 11:42:34 GMT -8 Charles Stover said:

Self-invoking functions wouldn't stop those conflicts. Proper code would.

And since you have no control over what other people consider "proper code" it is up to you to protect your own code.
As an example ...

Nov 27, 2010 6:16:36 GMT -8 Charles Stover said:

<script type="text/javascript"><!--
var tables = document.getElementsByTagName("table"), x;
for (x = 0; x < tables.length; x++)
{
    if (tables.item(x).getAttribute("width") == "92%")
        tables.item(x).setAttribute("width", "700");
}
//--></script>

Those variables tables and x since not defined within the context of a function become the property of the global window object. Should an event, timer, callback, or any other asynchronous execution fire while that little script was running and that event function improperly used an x variable without first using the var keyword ultimately when control returns to your loop your x will be a completely different value resulting in unpredictable behavior (I linked to a couple examples if you still don't get the idea).
By placing your script within a function and then local scoping your variables you do not have to worry about whether someone else is "properly coding" their own script, your script will be protected and no other script can mess with it and cause a conflict.

Dec 4, 2010 11:42:34 GMT -8 Charles Stover said:

As mentioned before, code conflicts are due to referencing a variable in the future (e.g. on a timer) that may have changed as a result of another code.

The above example gives a realtime not future reference scenario

Dec 4, 2010 11:42:34 GMT -8 Charles Stover said:

If the code is executed on a timer, the function will need to be named anyway, not self-invoked. If the function is named (thus already exists as a functions, as opposed to functionless codes we're already discussing), the programmer is perfectly capable of defining that function's variables locally instead of globally. If their code conflicts, they defined their variables globally, and a self-invoked function wouldn't change that.

No it is doesn't, anonymous functions are functions too, there is no requirement in ECMA saying the function reference passed to the API has to be named.

(function(){
var myTable= document.getElementById('myTable');
setTimeout(function(){
do something using the myTable variable defined in parent function (aka closure)
},2000);
})()

What is wrong with anonymous functions used on a timer or event? Anonymous functions are not accessible from the global object thus protected from a script coming along before your timer or event triggers, and defining a function (or global variable) with the same name as the one you just created (thus redefining your function) and completely changing whatever you intended your function to do before it is invoked. By also defining your anonymous function within the context of another function you've bound variable access through closure thus resulting in more efficient coding. Your handler/timer/callback no longer has to redo the work already done to regain access to whatever DOM element is being targeted, it simply access the variable that was set in its ancestor functions.

Dec 4, 2010 11:42:34 GMT -8 Charles Stover said:

The only other alternative would be that they didn't adequately define their variables in a way as not to allow other codes to interfere with them - they just threw around the variable x without considering that they didn't necessarily personally define it.

Which is why you protect your own code by using encapsulation. You have no control over what anybody else does so take proactive measures to avoid conflicts. Proboards headers is a collection of competing codes not in the least concerned about what another code might be doing or even taking the time to minimize the impact of whatever it is they have done, so armor yourself for battle. You can't change the behavior of another code but you can change the behavior of your own.