JavaScript exploration: an alternative solution to naming function expressions

In fact, if we don't want this descriptive name, we can do it in the simplest form, that is

In fact, if we don't want this descriptive name, we can do it in the simplest form, that is, declare a function (rather than a function expression) inside the function ), then return the function:

Var hasClassName = (function () {// defines the private variable var cache ={}; // use the function to declare function hasClassName (element, className) {var _ className = '(? : ^ | \ S +) '+ className + '(? : \ S + | $) '; var re = cache [_ className] | (cache [_ className] = new RegExp (_ className); return re. test (element. className);} // return function return hasClassName ;})();

Obviously, this solution will not work if multiple branch function definitions exist. However, there is a pattern that can be implemented: define all functions using function declaration in advance and specify different identifiers for these functions:

  var addEvent = (function(){    var docEl = document.documentElement;    function addEventListener(){      /* ... */    }    function attachEvent(){      /* ... */    }    function addEventAsProperty(){      /* ... */    }    if (typeof docEl.addEventListener != 'undefined') {      return addEventListener;    }    elseif (typeof docEl.attachEvent != 'undefined') {      return attachEvent;    }    return addEventAsProperty;  })();

Although this solution is elegant, it does not have any disadvantages. First, because different identifiers are used, naming consistency is lost. Not to mention whether this is good or bad, at least it is not clear enough. Some people like to use the same name, but some do not care about the word difference. After all, different names can be thought of as different implementations. For example, if you see attachEvent In the debugger, we know that addEvent is implemented based on attachEvent. However, implementation-based naming is not necessarily feasible. Suppose we want to provide an API and name the function as inner in this way. Then, API users are easily confused by the implementation details.

To solve this problem, you must think of a more reasonable naming scheme. But the key is not to make extra effort. I can think of the following solutions:

'Addevent', 'altaddevent', 'upload' // or 'addevent', 'addevent2', 'addevent3' // or 'addevent _ addEventListener ', 'addevent _ attachEvent ', 'addevent _ asproperties'

In addition, this mode also has a small problem, that is, increasing memory usage. Create N functions with different names in advance, which means that functions with N-1 are not used. Specifically, if document.doc umentElement contains attachEvent, then addEventListener and addEventAsProperty are useless. However, they all occupy the memory, and these memories will never be released, the reason is the same as that of the JScript naming expression-both functions are "intercepted" in the closure of the returned function.

However, it is no big deal to increase memory usage. If a library, such as Prototype. js, adopts this mode, it is nothing more than creating 100 or 200 more functions. As long as these functions are not repeatedly created (at runtime), but only created once (during loading), there is no worries.

Additional reading

The topic list of this article is as follows:

1. How should we understand the working principle of the JavaScript engine?
2. JavaScript exploration: the importance of writing maintainable code
3. JavaScript exploration: exercise caution when using global variables
4. JavaScript exploration: var pre-parsing and side effects
5. JavaScript exploration: for Loop (for Loops)
6. JavaScript exploration: for-in loop (for-in Loops)
7. Exploring JavaScript: Prototypes is too powerful
8. JavaScript: eval () is the devil"
9. JavaScript exploration: Using parseInt () for Numerical Conversion
10. Exploring JavaScript: Basic coding specifications
11. JavaScript exploration: function declaration and function expression
12. JavaScript exploration: Name function expressions
13. JavaScript: function name in the debugger
14. JavaScript: JScript Bug
15. JavaScript exploration: Memory Management of JScript
16. Exploring JavaScript: SpiderMonkey's quirks
17. JavaScript exploration: an alternative solution to naming function expressions
18. JavaScript exploration: Object
19. JavaScript exploration: Prototype chain
20. JavaScript exploration: Constructor
21. JavaScript probing: executable context Stack
22. Execution context 1: Variable object and activity object
23. Execution context 2: Scope chain Scope Chains
24. Execution context 3: Closure Closures
25. Execution context 4: This pointer
26. Exploring JavaScript: Powerful prototype and prototype chain
27. JavaScript Functions 1: function declaration
28. JavaScript function 2: function expressions
29. JavaScript function 3: function expressions in a group
30. JavaScript function 4: function Constructor
31. JavaScript variable object 1: VO Declaration
32. JavaScript variable object 2: VO in different execution contexts
33. JavaScript variable object 3: two stages of execution Context
34. JavaScript variable object IV: Variables
35. Property of the JavaScript variable object __parent _
36. JavaScript scope chain 1: Scope chain Definition
37. JavaScript scope chain 2: function Lifecycle
38. JavaScript scope chain 3: Scope chain features
39. JavaScript closure 1: Introduction to closures
40. JavaScript closure 2: Implementation of closure
41. JavaScript closure 3: Closure usage

This article is available at http://www.nowamagic.net/librarys/veda/detail/1639.