Changeset 18262 for branches/FACT++_scripts_refactoring/explicit_changelog
- Timestamp:
- 06/23/15 15:41:44 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
branches/FACT++_scripts_refactoring/explicit_changelog
r18239 r18262 13 13 As script works nicely, but somebody needs additional output, so a new variable is created in the top of Main.js: 14 14 15 15 var i_am_already_used_inside_an_included_script = some_value; 16 16 17 17 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. … … 24 24 25 25 A) There are no scripts to be included, that have side-effects. 26 26 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. 27 27 28 28 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 … … 30 30 31 31 Example: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 32 # great_functions.js 33 34 var great_functions = { 35 36 scoped_variable1 : "foo", 37 38 great_function1 : function(parameter1){ 39 console.out(parameter1); 40 }, 41 42 great_function2 :function(){ 43 console.out(this.scoped_variable1); 44 }, 45 }; 46 46 47 47 Use the functions from great_functions.js like: 48 48 49 50 great_functions.great_function1("foo");// --> foo51 52 great_functions.great_function2();// --> bar53 49 include("great_functions.js"); 50 great_functions.great_function1("foo"); // --> foo 51 great_functions.scoped_variable1 = "bar"; 52 great_functions.great_function2(); // --> bar 53 54 54 55 55 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: … … 67 67 Let new_lib.js create the scope and include all parts of the library inside new_lib.js: 68 68 69 70 71 72 73 69 # new_lib.js 70 71 var new_lib = {}; 72 include("part1.js"); 73 include("part2.js"); 74 74 75 75 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: 76 76 77 78 79 80 81 77 # par1.js 78 79 new_lib.a_function = function(){ 80 // do something astonishing! 81 }; 82 82 83 83 84 84 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: 85 85 86 87 88 89 86 # main_like.js 87 88 include("new_lib/new_lib.js"); 89 new_lib.a_function(); 90 90 91 91 … … 105 105 106 106 Okay so, this is more tricky. CheckUnderflow.js includes 4 more scripts. 107 107 CheckStates.js is included in CheckUnderflow.js *and* in Startup.js 108 108 109 109 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: 110 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 111 # library.js 112 // this should be the global context, *if* include('library.js') 113 // was called in a global context. 114 if (!('library' in this)){ 115 var library = { 116 some_func : function(){ 117 118 }, 119 another_func : function(){ 120 121 }, 122 }; 123 } 124 //maybe even: 125 else{ 126 console.out("multiple include of 'library.js' "); 127 } 128 128 129 129 So I add, this new "include guard" to CheckFTU.js quickly. … … 181 181 182 182 # ---------------------------------------------------------------------- 183 184 I just remembered, I should mention what I donÄt like about Hist1D.js and Hist2D.js 185 (I mean apart from the fact, that this code would not be needed, 186 when we had used Python+PyDim instead of Javascript and a custom made JS interpreter.) 187 I don't like that Hist1D() and Hist2D() *claim* to be a constructors, but in fact they are not. 188 189 If you did: 190 var h = Hist1D.Hist1D(100, 0, 100); 191 console.out(h instanceof Hist1D); 192 you would get a 'false'. 193 194 Also the fact, that one always has to call constructors with new, does not apply for Hist1D or Hist2D, why? 195 In strict mode, not calling a constructor with new, will even cause an exception. But calling Hist1D() with or without new, does not make a difference at all. 196 197 Should be changed. 198 199 # ---------------------------------------------------------------------- 200 201
Note:
See TracChangeset
for help on using the changeset viewer.