source: branches/FACT++_scripts_refactoring/explicit_changelog@ 18233

18.06.2016:
-----------

Start of Refactoring.

The entire FACT++/scripts folder contains ~5k lines of JS code, hardly documented at all. Yes, there are comments, but this is mostly commented out code, not anything that tries make the design choices clear to the reader.But this is not what worries me most. 

Mostly I am worried about, what I like to call "global include with side-effects".
AFAIK in ECMAScript 5 there is nothing like an include command, but in our FACT++ JS dialect, we have include(). From what I infer, this function will simply insert the mentioned script at its own position. Much like the C-preprocessor would execute a #include. 

This means, by including another script, one does not only make new functions and objects available, but one can also (unknowingly) execute code. Even more, this inserted script is inserted into the global scope (mostly), so it has access to all the variables and functions, previously defined and can alter them. So that after an include(), one cannot be sure about the state ones variables. I can imagine, a nice source of error would be the following:

As script works nicely, but somebody needs additional output, so a new variable is created in the top of Main.js:

        var i_am_already_used_inside_an_included_script = some_value;

Further down the line, there is an include(), which alters the value of "i_am_already_used_inside_an_included_script", because it happened to use the same variable name.

Further down, our new variable has a different value, and we just don't see why. 

#-------------------------------------------------------------

So to sum it up. I would like it best, when.

A) There are no scripts to be included, that have side-effects.
        I.e. All scripts, which are included into the Main.js or any other main-like script, should only create new functions, or reference types (aka classes), but never call any function or instanciate new objects.

B) Even better: Scripts, which are written, to be included into a main-like script, should simply create their own scope. If they have their own scope, of course they may create instances of new classes, or any other variable, which stays bound to the 
scope of the script. They still *should not* execute any code, I'd say.

Example:
        # great_functions.js

        var great_functions = {

                scoped_variable1 : "foo",

                great_function1 : function(parameter1){
                        console.out(parameter1);
                },
                
                great_function2 :function(){
                        console.out(this.scoped_variable1);
                },
        };

Use the functions from great_functions.js like:

        include("great_functions.js");
        great_functions.great_function1("foo");         // --> foo
        great_functions.scoped_variable1 = "bar";
        great_functions.great_function2();                      // --> bar
        

C) If one wants to create a lot of funtions, which should go into one single scope, like a library for example. I'd suggest to do it like this:

Create a folder for the library and inside that folder create a file called like the library as well. 

new_lib/
   |
   |----new_lib.js
   |
   |----part1.js
   |
   |----part2.js

Let new_lib.js create the scope and include all parts of the library inside new_lib.js:

        # new_lib.js

        var new_lib = {};
        include("part1.js");
        include("part2.js");

Then inside the parts of the library (names can be chosen arbitraryly of course.) attach the new functions or reference types to the namespace created in new_lib.js:

        # par1.js

        new_lib.a_function = function(){
                // do something astonishing!
        };


Of course all this heavily relies on convention, and not to break the convention. But I think, it would work. In the main-like script, which wants to use a_function() just do:

        # main_like.js

        include("new_lib/new_lib.js");
        new_lib.a_function();



# --------------------------------------------------------------

So there we are ... I am now on the mission of scoping scripts and removing side-effects. 

I'll start with side-effects, because they are much worse, than missing scope.

So I'll start with "CheckFTU.js", which is included in "Startup.js"

Okay, took me 5 minutes. not bad. 

next is:
"CheckUnderflow.js"

Okay so, this is more tricky. CheckUnderflow.js includes 4 more scripts.
        CheckStates.js is included in CheckUnderflow.js *and* in Startup.js

I think, it is time to invent something like include-guards. So, when a library is included another time, it checks, weather it was already included. Maybe like this:

        # library.js
        // this should be the global context, *if* include('library.js')
        // was called in a global context. 
        if (!('library' in this)){
                var library = {
                        some_func : function(){

                        },
                        another_func : function(){

                        },
                };
        }
        //maybe even: 
        else{
                console.out("multiple include of 'library.js' ");
        }

So I add, this new "include guard" to CheckFTU.js quickly.

Still we need to decide, what we want to do, when include() is called
inside a libraries scope. Currently it would be included, into that namespace, and stay there. Which is probably just fine. So... 
let's got for it, and see how it works.

# ------------------------------------------------------------------------
So CheckUnderflow.js is done. Now I look at: CheckStates.js which is included by CheckUnderflow.js.

Okay, I'm done inside CheckStates.js, now I need to see, how the functions are called.

While doing CheckStates.js, I realized, that functions which are part of a scope now, cannot refer to each other directly, as they could do before.
Now when once function inside a library wants to call another function, it must refer to it, using this. This is a bit more to write, but it makes it also clear, where the function, which is called, comes from. So for the sake of expliciteness. I'll do it.

Now I do Hist1D.js and Hist2D.js. Also I must say, I found a little library, being defined inside CheckUnderflow, which is the Func object.

So I will create a Func.js for this.
# ----------------------------------------------------------------------

Okay now I look at takeRun.js