CrazyPython
diff --git a/‎1-js/3-object-basics/1-object/article.md‎
Lines changed: 3 additions & 9 deletions b/‎1-js/3-object-basics/1-object/article.md‎
Lines changed: 3 additions & 9 deletions
diff --git a/‎1-js/6-data-structures/3-string/article.md‎
Lines changed: 4 additions & 2 deletions b/‎1-js/6-data-structures/3-string/article.md‎
Lines changed: 4 additions & 2 deletions
diff --git a/‎1-js/7-deeper/2-closure/article.md‎
Lines changed: 123 additions & 1 deletion b/‎1-js/7-deeper/2-closure/article.md‎
Lines changed: 123 additions & 1 deletion
diff --git a/‎1-js/7-deeper/3-function-object/article.md‎
Lines changed: 85 additions & 57 deletions b/‎1-js/7-deeper/3-function-object/article.md‎
Lines changed: 85 additions & 57 deletions
@@ -235,22 +235,16 @@ let obj = {
 alert( obj.for + obj.let + obj.return );  // 6
 ```
 
-Basically, any name is allowed, with one exclusion: `__proto__`. 
-
-The built-in property named `__proto__` has a special functionality (we'll cover it later), and it can't be set to a non-object value:
+Basically, any name is allowed, but there's a special one: `"__proto__"`. We can't set it to a non-object value:
 
 ```js run
-let obj = {};
-obj.__proto__ = 5;
+let obj = { __proto__: 5 };
 alert(obj.__proto__); // [object Object], didn't work as intended
 ```
 
-As you we see from the code, an assignment to a primitive is ignored. If we want to store *arbitrary* (user-provided) keys, then such behavior can be the source of bugs and even vulnerabilities, because it's unexpected. There's another data structure [Map](info:map-set-weakmap-weakset), that we'll learn in the chapter <info:map-set-weakmap-weakset>, which supports arbitrary keys.
+Later we'll learn more about that `__proto__` and see how to work around it [todo Object.create(null)]. Also we'll learn another data structure [Map](info:map-set-weakmap-weakset) that doesn't have such problems and supports arbitrary keys.
 ````
 
-
-
-
 ## Existance check
 
 A notable objects feature is that it's possible to access any property. There will be no error if the property doesn't exist! Accessing a non-existing property just returns `undefined`. It provides a very common way to test whether the property exists -- to get it and compare vs undefined:
 
@@ -451,7 +451,9 @@ Let's recap the methods to avoid any confusion:
 
 
 ```smart header="Which one to choose?"
-All of them can do the job. The author finds himself using `slice` almost all the time.
+All of them can do the job. Formally, `substr` has a minor drawback: it is described not in the core Javascript specification, but in Annex B, which covers browser-only features that exist mainly for historical reasons. So, non-browser environments may fail to support it. But in practice it works everywhere.
+
+The author finds himself using `slice` almost all the time.
 ```
 
 ## Comparing strings
@@ -526,7 +528,7 @@ The characters are compared by their numeric code. The greater code means that t
 
 ### Correct comparisons
 
-The "right" algorithm to do string comparisons is more complex than it may seem. Because the alphabets are different for different languages. So the same letter may be located differently in different alphabets, that is -- even if it looks the same, different alphabets put it in different place.
+The "right" algorithm to do string comparisons is more complex than it may seem. Because alphabets are different for different languages. The same-looking letter may be located differently in different alphabets.
 
 So, the browser needs to know the language to compare.
 
 
@@ -420,6 +420,129 @@ There are other ways to do that:
 }();
 ```
 
+## Garbage collection
+
+Lexical Environment objects that we've been talking about follow same garbage collection rules as regular ones.
+
+So, a Lexical Environment exists while there's a nested function referencing it with its `[[Environment]]`.
+
+- Usually, Lexical Environment is cleaned up after the function run. Even if it has a nested function, for instance:
+
+    ```js
+    function f() {
+      let value = 123;
+
+      function g() {} // g is local
+    }
+
+    f();
+    ```
+
+    Here both `value` and `g` become unreachable after the end of `f()`, and so even though `g` references its outer lexical environment, that doesn't matter.
+
+- But if `g` were returned and kept reachable, then that its reference keeps the outer lexical environment alive as well:
+
+    ```js
+    function f() {
+      let value = 123;
+
+      function g() {}
+
+    *!*
+      return g;
+    */!*
+    }
+
+    let g = f(); // function g will live and keep the outer lexical environment in memory
+    ```
+
+- If `f()` is called many times, and resulting functions are saved, then the corresponding Lexical Environment objects will also be retained in memory. All 3 of them in the code below:
+
+    ```js
+    function f() {
+      var value = Math.random();
+
+      return function() {};
+    }
+
+    // 3 functions in array, every of them links to LexicalEnvrironment
+    // from the corresponding f() run
+    let arr = [f(), f(), f()];
+    ```
+- A Lexical Environment object lives until it is reachable. In the code below, after `g` becomes unreachable, it dies with it:
+
+    ```js
+    function f() {
+      var value = 123;
+
+      function g() {}
+
+      return g;
+    }
+
+    let g = f(); // while g is alive
+    // there corresponding Lexical Environment lives
+
+    g = null; // ...and now the memory is cleaned up
+    ```
+
+### Real-life optimizations
+
+As we've seen, in theory while a function is alive, all outer variabels are also retained. 
+
+But in practice, JS engines try to optimize that. They analyze variable usage and if it's easy to see that an outer variable is not used -- it is removed.
+
+In the code above `value` is not used in `g`. So it will be cleaned up from the memory.
+
+**Important side effect in V8 (Chrome, Opera) is that such variable will become unavailable in debugging!**
+
+Try running the example below with the open Developer Tools in Chrome.
+
+When it pauses, in console type `alert(value)`.
+
+```js run
+function f() {
+  var value = Math.random();
+
+  function g() {
+    debugger; // in console: type alert( value ); No such variable!
+  }
+
+  return g;
+}
+
+var g = f();
+g();
+```
+
+As you could see -- there is no such variable! The engine decided that we won't need it and removed it.
+
+That may lead to funny (if not such time-consuming) debugging issues, especially when we can see instead of *our* variable the more outer one:
+
+```js run global
+let value = "Surprise!";
+
+function f() {
+  let value = "the closest value";
+
+  function g() {
+    debugger; // in console: type alert( value ); Surprise!
+  }
+
+  return g;
+}
+
+let g = f();
+g();
+```
+
+```warn header="See ya!"
+This feature of V8 is good to know. If you are debugging with Chrome/Opera, sooner or later you will meet it.
+
+That is not a bug of debugger, but a special feature of V8. Maybe it will be changed sometimes. 
+You always can check for it by running examples on this page.
+```
+
 
 ## The old "var"
 
@@ -586,7 +709,6 @@ The features described above make using `var` inconvenient most of time. First,
 
 
 
-
 ## Global object
 
 A *global object* is the object that provides access to built-in functions and values, defined by the specification and the environment.
 
@@ -170,11 +170,11 @@ alert( counter() ); // 0
 alert( counter() ); // 1
 ```
 
-Unlike the closures, the `count` is now bound to the function directly, not to its outer Lexical Environment.
+Unlike examples from chapter <info:closure>, the `count` is now stored in the function directly, not in its outer Lexical Environment.
 
 Is it worse or better than using the closure?
 
-The main difference is that if the value of `count` lives in an outer variable, then an external code is unable to access it. Only the nested function may modify it. And if it's bound to function, then such thing is possible:
+The main difference is that if the value of `count` lives in an outer variable, then an external code is unable to access it. Only nested functions may modify it. And if it's bound to function, then such thing is possible:
 
 ```js run
 function makeCounter() {
@@ -196,108 +196,136 @@ alert( counter() ); // 10
 */!*
 ```
 
-Sometimes such possibility can be a plus, but usually we want more control over `count`, and hence the closure is more often used.
+So it depends on our aims which variant to choose.
 
 ## Named Function Expression
 
-Compare these two function definitions:
+Named Function Expression or, shortly, NFE, is a term a Function Expression that has a name.
+
+For instance, let's take an ordinary Function Expression:
 
 ```js
-let sayHi = function() { // (1)
-  alert('Hello');
+let sayHi = function(who) {
+  alert(`Hello, ${who}`);
 };
+```
+
+...And add a name to it:
 
-let sayHi = function *!*func*/!*() { // (2)
-  alert('Hello');
+```js
+let sayHi = function *!*func*/!*(who) {
+  alert(`Hello, ${who}`);
 };
 ```
 
-Both create a function and put it into the variable `sayHi`. And usually we use the first variant is fine.
+What's the role of that additional `"func"` name?
 
-But if we specify a name right in the Function Expression (2), then it becomes an "internal function name", only visible from inside the function.
+First let's note, that we still have a Function Expression. Adding the name `"func"` after `function` did not make it a Function Declaration, because it is still created as a part of an assignment expression.
 
-Let's see why we may need it.
+Adding such a name also did not break anything.
 
-As we've seen it's easy to copy a function and maybe replace the previous value with something else:
+The function is still available as `sayHi()`:
 
-```js run
-let sayHi = function() {
-  alert('Hello');
+```js run 
+let sayHi = function *!*func*/!*(who) {
+  alert(`Hello, ${who}`);
 };
 
-// oh maybe another word is better? replace it!
-let oldSayHi = sayHi; // keep the old variant here
-sayHi = function() { //  replace with a newer one
-  alert("What's up dude?");
+sayHi("John"); // Hello, John
+```
+
+There are two special things about the name `func`:
+
+1. It allows to reference the function from inside itself.
+2. It is not visible outside of the function.
+
+For instance, the function `sayHi` below re-calls itself with `"Guest"` if no `who` is provided:
+
+```js run
+let sayHi = function *!*func*/!*(who) {
+  if (who) {
+    alert(`Hello, ${who}`);
+  } else {
+*!*
+    func("Guest"); // use func to re-call itself
+*/!*
+  }
 };
 
+sayHi(); // Hello, Guest
 
-oldSayHi(); // Hello 
-sayHi(); // What's up dude?
+// But this won't work:
+func(); // Error, func is not defined (not visible outside of the function)
 ```
 
-The problem may occur if a function references *itself* from inside. It happens when the function wants to access its properties (`sayHi.counter` in the example above), or it wants to recursively call itself one more time.
+Why do we use `func`? Maybe just use `sayHi` for the nested call?
 
-But if the function has moved, then the old name becomes irrelevant! There will be an error.
 
-Here's the code:
+Actually, in most cases we can:
 
-```js run
-// create a function
-let sayHi = function() {
-  sayHi.counter++;
-  alert('Hi ' + sayHi.counter);
+```js
+let sayHi = function(who) {
+  if (who) {
+    alert(`Hello, ${who}`);
+  } else {
+*!*
+    sayHi("Guest");
+*/!*
+  }
 };
-sayHi.counter = 0; 
+```
 
-// move it 
-let movedSayHi = sayHi;
-
-// overwrite the old name to make things more obvious
-sayHi = null;
+The problem with that code is that the value of `sayHi` may change. The function may go to another variable, and the code will start to give errors:
 
+```js run
+let sayHi = function(who) {
+  if (who) {
+    alert(`Hello, ${who}`);
+  } else {
 *!*
-movedSayHi(); // Error: Cannot read property 'counter' of null
+    sayHi("Guest"); // Error: sayHi is not a function
 */!*
+  }
+};
+
+let welcome = sayHi;
+sayHi = null;
+
+welcome(); // Error, the nested sayHi call doesn't work any more!
 ```
 
-The optional name which we can put into the Function Expression is exactly meant to solve this kind of problems.
+That happens because the function takes `sayHi` from its outer lexical environment. There's no local `sayHi`, so the outer variable is used. And at the moment of the call that outer `sayHi` is `null`.
 
-- It is only visible from inside the function.
-- It always references the current function.
+The optional name which we can put into the Function Expression is exactly meant to solve this kind of problems.
 
 Let's use it to fix the code:
 
 ```js run
-// now with the internal name "say"
-let sayHi = function *!*say*/!*() {
-  *!*say*/!*.counter++; 
-  alert('Hi ' + *!*say*/!*.counter); // and use it everywhere inside
+let sayHi = function *!*func*/!*(who) {
+  if (who) {
+    alert(`Hello, ${who}`);
+  } else {
+*!*
+    func("Guest"); // Now all fine
+*/!*
+  }
 };
-sayHi.counter = 0; 
-
-let movedSayHi = sayHi;
 
+let welcome = sayHi;
 sayHi = null;
 
-movedSayHi(); // Hi 1
-movedSayHi(); // Hi 2 (works)
-
-alert(say); // Error (say is undefined, that's normal)
+welcome(); // Hello, Guest (nested call works)
 ```
 
-Please note that:
-
-- The name `say` exists only inside the function. The last line demonstrates that.
-- The name `say` inside the function is always the current function, no matter in which variable it is. That's why it works.
+Now it works, because the name `"func"` is function-local. It is not taken from outside (and not visible there). The specification guarantees that it always references the current function.
 
-So the outer code has it's variable `sayHi` or `movedSayHi` later to call the function. The `say` is an "internal function name", how it calls itself privately.
-
-A Function Expression with a name is called *Named Function Expression*, often abbreviated as NFE.
+The outer code still has it's variable `sayHi` or `welcome` later. And `func` is an "internal function name", how it calls itself privately.
 
+```smart header="No such thing for Function Declaration"
 The "internal name" feature described here is only available for Function Expressions, not to Function Declarations. For Function Declarations, there's just no syntax possibility to add a one more "internal" name for them. 
 
 Sometimes, when we need a reliable internal name, it's the reason to rewrite a Function Declaration to Named Function Expression form.
+```
 
 ## Summary