Perfection Kills

  >>> var sum = function(a, b) {return a + b;}
  >>> var add = sum;
  >>> delete sum
  true
  >>> typeof sum;
  "undefined"
  

  var o = { x: 1 };
  delete o.x; // true
  o.x; // undefined
  

  var x = 1;
  delete x; // false
  x; // 1
  

  function x(){}
  delete x; // false
  typeof x; // "function"
  

  /* remember that `this` refers to global object when in global scope */
  var GLOBAL_OBJECT = this;

  var foo = 1;
  GLOBAL_OBJECT.foo; // 1
  foo === GLOBAL_OBJECT.foo; // true

  function bar(){}
  typeof GLOBAL_OBJECT.bar; // "function"
  GLOBAL_OBJECT.bar === bar; // true
  

  (function(foo){

    var bar = 2;
    function baz(){}

    /*
    In abstract terms,

    Special `arguments` object becomes a property of containing function's Activation object:
      ACTIVATION_OBJECT.arguments; // Arguments object

    ...as well as argument `foo`:
      ACTIVATION_OBJECT.foo; // 1

    ...as well as variable `bar`:
      ACTIVATION_OBJECT.bar; // 2

    ...as well as function declared locally:
      typeof ACTIVATION_OBJECT.baz; // "function"
    */

  })(1);
  

  var GLOBAL_OBJECT = this;

  /* `foo` is created as a property of calling context Variable object,
      which in this case is a Global object */

  eval('var foo = 1;');
  GLOBAL_OBJECT.foo; // 1

  (function(){

    /* `bar` is created as a property of calling context Variable object,
      which in this case is an Activation object of containing function */

    eval('var bar = 1;');

    /*
      In abstract terms,
      ACTIVATION_OBJECT.bar; // 1
    */

  })();
  

  var GLOBAL_OBJECT = this;

  /*  `foo` is a property of a Global object.
      It is created via variable declaration and so has DontDelete attribute.
      This is why it can not be deleted. */

  var foo = 1;
  delete foo; // false
  typeof foo; // "number"

  /*  `bar` is a property of a Global object.
      It is created via function declaration and so has DontDelete attribute.
      This is why it can not be deleted either. */

  function bar(){}
  delete bar; // false
  typeof bar; // "function"

  /*  `baz` is also a property of a Global object.
      However, it is created via property assignment and so has no DontDelete attribute.
      This is why it can be deleted. */

  GLOBAL_OBJECT.baz = 'blah';
  delete GLOBAL_OBJECT.baz; // true
  typeof GLOBAL_OBJECT.baz; // "undefined"
  

  (function(){

    /* can't delete `arguments`, since it has DontDelete */

    delete arguments; // false
    typeof arguments; // "object"

    /* can't delete function's `length`; it also has DontDelete */

    function f(){}
    delete f.length; // false
    typeof f.length; // "number"

  })();
  

  (function(foo, bar){

    delete foo; // false
    foo; // 1

    delete bar; // false
    bar; // 'blah'

  })(1, 'blah');
  

  var GLOBAL_OBJECT = this;

  /* create global property via variable declaration; property has DontDelete */
  var foo = 1;

  /* create global property via undeclared assignment; property has no DontDelete */
  bar = 2;

  delete foo; // false
  typeof foo; // "number"

  delete bar; // true
  typeof bar; // "undefined"
  

  /* `foo` is created as a property with DontDelete */
  function foo(){}

  /* Later assignments do not modify attributes. DontDelete is still there! */
  foo = 1;
  delete foo; // false
  typeof foo; // "number"

  /* But assigning to a property that doesn't exist,
     creates that property with empty attributes (and so without DontDelete) */

  this.bar = 1;
  delete bar; // true
  typeof bar; // "undefined"

  eval('var foo = 1;');
  foo; // 1
  delete foo; // true
  typeof foo; // "undefined"
  

  (function(){

    eval('var foo = 1;');
    foo; // 1
    delete foo; // true
    typeof foo; // "undefined"

  })();
  

  function x(){ }
  var x;
  typeof x; // "function"
  

  var x = 1;

  /* Can't delete, `x` has DontDelete */

  delete x; // false
  typeof x; // "number"

  eval('function x(){}');

  /* `x` property now references function, and should have no DontDelete */

  typeof x; // "function"
  delete x; // should be `true`
  typeof x; // should be "undefined"
  

    function foo(){}
    delete foo; // false (as expected)
    typeof foo; // "function" (as expected)

    /* now assign to a property explicitly */

    this.foo = 1; // erroneously clears DontDelete attribute
    delete foo; // true
    typeof foo; // "undefined"

    /* note that this doesn't happen when assigning property implicitly */

    function bar(){}
    bar = 1;
    delete bar; // false
    typeof bar; // "number" (although assignment replaced property)
  

    this.x = 1;
    delete x; // TypeError: Object doesn't support this action
  

    var x = 1;
    delete this.x; // TypeError: Cannot delete 'this.x'
  

    this.x = 1;

    delete this.x; // TypeError: Object doesn't support this action
    typeof x; // "number" (still exists, wasn't deleted as it should have been!)

    delete x; // TypeError: Object doesn't support this action
    typeof x; // "number" (wasn't deleted again)
  

    x = 1;
    delete x; // true
    typeof x; // "undefined"
  

    x = 1;
    delete this.x; // TypeError: Cannot delete 'this.x'
  

    /* in Global code */
    function getBase(){ return this; }

    getBase() === this.getBase(); // false
    this.getBase() === this.getBase(); // true
    window.getBase() === this.getBase(); // true
    window.getBase() === getBase(); // false
  

    /* "alert" is a direct property of `window` (if we were to believe `hasOwnProperty`) */
    window.hasOwnProperty('alert'); // true

    delete window.alert; // true
    typeof window.alert; // "function"
  

  (function(foo){

    "use strict"; // enable strict mode within this function

    var bar;
    function baz(){}

    delete foo; // SyntaxError (when deleting argument)
    delete bar; // SyntaxError (when deleting variable)
    delete baz; // SyntaxError (when deleting variable created with function declaration)

    /* `length` of function instances has { [[Configurable]] : false } */

    delete (function(){}).length; // TypeError

  })();
  

    "use strict";
    delete i_dont_exist; // SyntaxError
  

    "use strict";
    i_dont_exist = 1; // ReferenceError
  

Comments (72)

1. 

   qFox said on Jan 11, 2010 @ 10:08

   #1

   Nice (but lengthy ;) article. Seems to be correct though. Nice catch of the firebug issue.

   I remember IE is implementing the global object differently under the hood. Something about window != this in the global scope or something. I should test this when I have the time.

2. 

   Rob Wright said on Jan 11, 2010 @ 10:28

   #2

   Very interesting article, thanks for taking the time to give your insights. Just the kind of thing I need to improve my JS knowledge.

3. 

   Ryan Szulczewski said on Jan 11, 2010 @ 10:49

   #3

   Great article. The only thing that would have been more helpful if it would have explained when delete is useful (e.g. stopping memory leaks, performance, etc.)

4. 

   David Semeria said on Jan 11, 2010 @ 11:16

   #4

   Juriy, what an excellent post!

   I really appreciate the time you put into this, and found it very informative.

   Thanks!

5. 

   Asen Bozhilov said on Jan 11, 2010 @ 11:41

   #5

   Excellent article. When i read sentence after sentence i expect explanations of the things in my head and you make a sense about them.

   Only one mistake. In Spidermonkey global object has Prototype Chain. See code below:

   window.alert(this.__proto__); //[xpconnect wrapped native prototype]
   window.alert(this.__proto__.__proto__); //[object Global Scope Polluter]
   window.alert(this.__proto__.__proto__.__proto__); //[object Object]
   window.alert(this.__proto__.__proto__.__proto__ === Object.prototype); //true
   

   `hasOwnProperty` and `propertyIsEnumerable` lookups in Prototype chain for Global Object.

   Object.prototype.x = 10;
   window.alert(window.hasOwnProperty('x')); //true
   window.alert(window.propertyIsEnumerable('x')); //true
   

   The interesting part here is, Global Object inherit `hasOwnProperty` and `propertyIsEnumerable` from Object.prototype.

   window.alert(window.hasOwnProperty === Object.prototype.hasOwnProperty); //true
   window.alert(window.propertyIsEnumerable === Object.prototype.propertyIsEnumerable); //true
   

   `alert` prototype is defined in Global Object[[Prototype]]. Your example should be change to:

   window.alert(window.__proto__.__proto__.hasOwnProperty('alert')); //false
   window.alert(window.__proto__.hasOwnProperty('alert')); //true
   window.alert(delete window.__proto__.alert); //true
   
   window.alert('test'); //display test
   

   Regards for excellent article ;~)

6. 

   Asen Bozhilov said on Jan 11, 2010 @ 13:13

   #6

   Regarding my previous post. Global Object and Global Object[[Prototype]] in Spidermonkey have owns internal [[GetOwnProperty]] method.
   Regarding:
   
window.__proto__;

   This object has own [[Get]].

   window.__proto__.alert = false;
   console.log(typeof window.alert); //boolean
   console.log(delete window.__proto__.alert); //true
   console.log(typeof window.alert); //function
   

   Seems like lookup in prototype chain. But the next object in prototype chain doesn’t have property `alert`. So i think, `window.__proto__` has own implementation of [[Get]] method.

7. 

   M said on Jan 11, 2010 @ 14:27

   #7

   @Juriy:

   Did you read more of the book? If so, would you recommend it (or were there other errors you noticed)?

8. 

   zorg said on Jan 11, 2010 @ 19:58

   #8

   I ‘d be interested to know more about the difference between function declarations and function expressions

9. 

   Ken Snyder said on Jan 11, 2010 @ 20:51

   #9

   Thanks for sharing your research! Very helpful.

10. 

    Raphael Speyer said on Jan 12, 2010 @ 5:40

    #10

    Good post!

    However, the behaviour that you describe with “Not only does function declaration replaces previous value of a property, it also replaces that property attributes” is true for ES3 but not ES5.

    In the ES5 spec (10.5 steps 5d and 5e), if there is already a binding for ‘x’, CreateMutableBinding will not be called again but SetMutableBinding will, so the property value will be changed but not whether it is deletable. This means that tests 23 and 24 in your suite will always fail for ES5.

    I guess those tests are failing in most modern browsers because implementers are moving their ES3 engines to ES5.

11. 

    Jordan said on Jan 12, 2010 @ 8:44

    #11

    Great explanation. The length – while daunting – really is necessary if you are to understand delete at the level that you need in order to debunk the book’s usage. I do agree with Ryan above, however, in that it would be nice to see some proper usage of delete (to control memory leaks mostly in my experience).

    And to echo “M”‘s sentiment above… did you read more of the book? Were there many other inaccuracies?

12. 

    Pari Nannapaneni said on Jan 12, 2010 @ 14:58

    #12

    Great post !

    I was just declaring ‘window.variablename = .. ‘ for any variables that i wanted
    to delete later ( to store some temporary JSON result or something)

    After reading this post now i am now a lot more comfortable using the ‘delete’

    thanks for explaining.

13. 

    Grigory Kruglov said on Jan 12, 2010 @ 16:29

    #14

    Nice article!

    One note though, which you might find interesting, regarding this statement:
    Unfortunately, this kind of spoofing doesn’t work in any implementation I tried. I might be missing something here, or this behavior might simply be too obscure for implementors to pay attention to.

    It is implemented properly in the BlackBerry browser :-) Just ran the test on my Bold 9700 to double check, and surely enough I see all 24 green PASSes.

14. 

    kangax (article author) said on Jan 13, 2010 @ 10:37

    #15

    @Ryan Szulczewski, @Jordan

    You’re right. I should have explained when to use delete, before delving into all the details on how it works. The point of this overview was mainly to emphasize that deleting variables is useless (unless those are declared within eval, which is very unlikely), and even not very future-compatible (due to ES5 strict mode behavior). Deleting properties of native, user-defined objects is perfectly fine, and there are certainly valid use cases for that.

    In Prototype.js, there’s an Element method which is an abstraction for DOM element creation. This method accepts object as a second argument, iterates over it and maps name/value of object properties to element attributes. Now, in some environments, setAttribute is faulty and can not set “name” attribute on element after its creation. Instead, that environment supports extended element creation syntax — document.createElement('<a name="foo">'). To work around that, when this deficiency is detected, we remove “name” property from an object and use this extended syntax. We then iterate over the remaining properties, operating on each one of them as we normally would. A perfectly valid use case for delete.

    When using object as a hash table, one might need to delete certain property, so that iterating over an object, or using in operator (or Object.prototype.hasOwnProperty) would properly report property as being non-existent. Note that simply assigning null or even undefined does not actually delete a property. It is still visible when iterating with for-in or using one of the above mentioned ways of inspection.

    Speaking of memory leaks, breaking circular references — the cause of the leaks — is usually done with simple null assignment. There’s usually no need to use delete. Moreover, null‘ing allows to “dereference” variables — what delete would normally not be able to do.

    var el = document.getElementById('foo');
    
    // circular reference is formed
    el.onclick = function() { /* ... */ };
    
    // circular reference is broken
    el = null;
    
    // can't `delete el` in this case, as `el` has DontDelete
    

    For these reasons, it’s best to stick with null‘ing when breaking circular references.

15. 

    kangax (article author) said on Jan 13, 2010 @ 10:50

    #16

    Thanks everyone! I’m glad you enjoyed it.

    @zorg
    You can read about differences between function expressions and function declarations in my NFE article.

    @Grigory Kruglov
    Woah, I did not expect that. Thanks for this discovery! Just checked emulators of Blackberry 9530 (Storm), 9000 (Bold), 8320 (Curve), and 8100 (Pearl), and they all pass test suite fully, including last 2 assertions. Very surprising.

    @Raphael Speyer
    Ah, that’s interesting. Thanks for bringing it up. However, I don’t think current browser failures with changing property attributes have to do with ES5. Even older browsers — going back 5-10 years ago — exhibit absolutely the same behavior. And as per Grigory Kruglov’s comment, we now know that Blackberry browsers are compliant in this regard.

16. 

    kangax (article author) said on Jan 13, 2010 @ 11:24

    #17

    @M, @Jordan

    Unfortunately, I only read through chapter on functions. The book feels beginner-oriented, so this is who I would recommend it for. I also haven’t really noticed author touching advanced topics or explaining things deeply. I don’t think there’s much in it for advanced users, but then I haven’t seen other chapters.

    Some of the mistakes I noticed (besides this whole delete misunderstanding) were:

    - Saying that function f(){} and var f = function(){} are “exactly the same”. That’s not really true.
    - Saying that “A drawback, of course, is that you cannot execute the same function twice”, when talking about anonymous self executing function. Not true, since we have arguments.callee.
    - Various minor nitpicks, like not using proper terminology: calling function expression “function literal” or global scope — “global namespace”. Not a big deal, of course, but I like when authors stick to standard terms (to avoid ambiguity and confusion).
    - Not mentioning Function constructor as a third way to create a function.

17. 

    Dmitry A. Soshnikov said on Jan 14, 2010 @ 12:33

    #18

    Hi, kangax.

    Good article, thanks.

    Some additions bellow:

    Safari 2.x and 3.0.4 have problems with deleting function arguments; those properties seem to be created without DontDelete, so it is possible to delete them

    Although this bug has been fixed in newer versions of Safari, Chrome which is also based on WebKit still has such bug – there’s no {DontDelete} for arguments (v. 3.0.195.38, WinXP):

    function test(a, b) {
      alert([typeof a, typeof b]); // number, number
    
      delete a;
      delete arguments[1];
    
      // undefined, undefined - in Chrome
      // number, number - in other
      alert([typeof a, typeof b]);
    }
    
    test(1, 2);

    Also, it will be useful to know, that Opera (at least v.10.10 WinXP) doesn’t set {DontDelete} for catch clause’s parameter (12.14, ES-3):

    try {
      throw 'error';
    } catch (e) {
    
      alert(typeof e); // string
    
      delete e;
    
      // undefined - in current Opera
      // string - in other
      alert(typeof e);
    }

    I wrote about this in c.l.js: http://groups.google.ru/group/comp.lang.javascript/msg/a18b00bc8be5d542?hl=en

    It’s as if variable declarations in Global code do not create properties on Global object in IE

    The situation with variable declaration and the global object and the window host object in IE is more interesting than seems at first sight ;)

    Having e.g. such data in IE:

    a = 10;
    this.b = 20;
    window.c = 30;
    var d = 40;

    and using internal debugger of IE8 we can suppose such structure of the variable object for the global code:

    VO = {
      window: {
        b: - ?,
        c: - ? - should be there
      },
      d: on entering - undefined, then - 40,
      a: 10 - created on execution
    };

    This also can be seen in example of “redefining” and deleting variable with the same name as some host property’s name, e.g. “navigator”:

    alert(navigator); // [object], OK
    alert(navigator.userAgent); // exactly that object we expect
    
    // now use variable declaration
    // using [eval] which should not
    // set {DontDelete}
    
    eval('var navigator;');
    alert(navigator); // undefined, OK
    
    // set new value
    navigator = 10;
    alert(navigator); // 10, OK
    
    // remove it from the base object
    // as navigator has no {DontDelete}
    delete navigator;
    
    alert(navigator); // [object], ;)
    
    // and exactly restored main
    // [navigator] host object
    alert(navigator.userAgent);

    And if we again see into debugger, will see the following picture:

    VO = {
      window: {
        ...
        navigator:
        ...
      },
      navigator: 10
    };

    Here’s my more detailed explanation: http://groups.google.ru/group/comp.lang.javascript/msg/c1572441853282c6?hl=en

    Stoyan Stefanov’s Object-Oriented Javascript.

    This book has much inaccurate information, especially in chapter about objects and prototypes.

    /ds

18. 

    Stoyan said on Jan 15, 2010 @ 14:49

    #19

    Thanks very much, kangax, this is an excellent writeup! Looks like a second edition of the book would be highly desirable :)

19. 

    Sylvester Hesp said on Feb 9, 2010 @ 10:34

    #22

    About function declarations are instantiated after variable declarations
    Are you sure about this? Because I think you have misinterpreted something here. Functiondefinitions do not overwrite variable definitions. The reason

    function x() { }
    var x;
    typeof x; // "function"

    works is because the variabel declaration does not actually declare a new variable, because a variable with the name “x” (the function) already exists. However, should you initialize the variable, like so:

    function x() { }
    var x = 1;
    typeof x; // "number"

    x actually becomes a number, because the reference to the function is overwritten.

    As far as I understand it, all functions in the current scope are declared before anything else. That’s why this outputs 2 rather than 1:

    function x() { return 1; }
    alert(x());
    function x() { return 2; }

    Of course, an eval() will overwrite a variable with the function definition because it’s only executed at the call site of eval() – it is not parsed with the rest of normal code.

    Note that this is based on actual implementations, I haven’t taken the time to actually read the standard about this so maybe all implementations and myself are wrong :)

20. 

    Java developer said on Feb 18, 2010 @ 16:21

    #24

    Very nice article!

21. 

    niaher said on Feb 21, 2010 @ 11:37

    #25

    Awesomeness! There should be more of such in-depth articles on the Internet. The drag-and-drop mentality will never be able to compete with this quality.

22. 

    tot2ivn said on Feb 28, 2010 @ 11:21

    #26

    Thanks for such a great in-depth article..!

23. 

    Marcel Duran said on Mar 31, 2010 @ 15:06

    #29

    Nice post kangax, very informative. I noticed that weird firebug delete behavior before then I ran the following commands:

    To see what’s been used to run firebug console:

    console.log(arguments.callee.toString())

    function (expr) {
        try {
            var result = window.eval(expr);
            if (typeof result != "undefined") {
                window.console.notifyFirebug([result], "evaluated", "firebugAppendConsole");
            }
        } catch (exc) {
            var result = exc;
            result.source = expr;
            window.console.notifyFirebug([result], "evaluateError", "firebugAppendConsole");
        }
    }

    In fact it’s using eval as you suspected.

    To see what is really been passed as argument to that function:

    console.log(arguments[0])

    with(_FirebugCommandLine){console.log(arguments[0])};

    It’s using with statement adding an extra lookup to the scope chain, so besides the eval code it also has its own scope for the code executed within it.

    console.log(this === _FirebugCommandLine) // true 

    I have a performance related question. According to Steve Souders‘ Even Faster Websites book, on chapter 2 (page 19) the authors (Ajaxian founders) suggest to simultaneously remove a node from the DOM and delete it like:

    delete nodeToDelete.parent.removeChild(nodeToDelete)

    They claim it gives a hint to the garbage collector to remove this unused element from memory. I’m not sure if it really does, I know JSLint complains about such line. Do you have any thoughts on this?

24. 

    kangax (article author) said on Apr 4, 2010 @ 9:02

    #31

    @Marcel Duran

    I find it hard to believe that delete nodeToDelete.parent.removeChild(nodeToDelete) (I suppose parent instead of parentNode is a typo?) gives a hint to garbage collector to remove element from memory. First of all, I’m not aware of any explicit hinting patterns except for global CollectGarbage method in JScript.

    Second, if we look closer at this expression, we’ll see that it’s really equivalent to delete nodeToDelete. This is because function call operator has higher precedence than delete operator, so nodeToDelete.parentNode.removeChild(nodeToDelete) expression is executed first, evaluates to nodeToDelete (since this is what removeChild is defined to return), and is than passed to delete operator. So what we really have here is delete nodeToDelete.

    Now, what happens next depends on how nodeToDelete is declared. If it’s a local variable (most likely), it should be a property of ActivationObject and have [[DontDelete]] set on, in which case delete nodeToDelete would essentially be a noop. The situation would be different if nodeToDelete was declared from within eval (or be part of an object injected into a scope via with statement, and not have [[DontDelete]]). Since both of latter cases are unlikely, this pattern mostly looks like a bogus ;)

25. 

    denisdeng said on Apr 11, 2010 @ 3:51

    #32

    good article! I have learned a lot from this. thank you! so I have translate　 into Chinese:
    http://www.denisdeng.com/?p=858

26. 

    bledi said on Jun 18, 2010 @ 5:14

    #34

    this article is a MUST read!

27. 

    Ray said on Jun 30, 2010 @ 1:56

    #35

    With all the inaccuracies mentioned above, will purchasing and learning from the book mess up my JS knowledge? I’ve read DOM Scripting and Bulletproof Ajax and wanted something to take me further and this book by Stoyan seems like a good choice. What’s your take?

28. 

    Joss said on Oct 23, 2010 @ 8:19

    #39

    Really excellent article, very insightful and have never considered this.

    Keep up the good work!

    Joss

29. 

    Rohit said on Dec 30, 2010 @ 23:20

    #42

    Very interesting post. One doesn’t usually find material describing the idiosyncrasies of Javascript implementation to such detail.
    I was about to post a doubt regarding use of delete on a sequential array & its implications on array length – Something I had encountered while working on Node.js.
    No need now that I have read abt array length in your newer post ‘How ECMAScript 5 still does not allow to subclass an array’.
    Thanks for both these enlightening posts :-) .

30. 

    Yuval said on Jan 28, 2011 @ 12:36

    #48

    This is the best article I’ve read about Javascript variable scope. Thanks!

31. 

    Lupons said on Feb 21, 2011 @ 11:44

    #49

    Excellent article. It is a bit lengthly but neccesary to understand what it needs to explain. Excellent work!

32. 

    Lars Gunther said on Mar 16, 2011 @ 6:12

    #50

    A quick test shows that the JavaScript console is a better choice than Firebug for testing. Had Stoyan done that perhaps the book would have had accurate information.

    I use the console when teaching and this reinforces my resolve to keep doing that.

33. 

    Pablo Benito said on Apr 16, 2011 @ 7:34

    #53

    Hi,
    It is a very interesting post!,

    I have a question about the section “Gecko DontDelete bug”
    You tell us that this.foo = 1 should not change the current Variable Object property defined previusly as a function. Then implicitly you are telling us that we can access current Variable Object properties acceding “this” properties. Why? Which is the actual relation within the current Variable Object and “this”.

    My example code :
    function X(a){
    console.log(a);//currentVariableObject.a this return 666
    console.log(this.a); //this return undefined
    }

    var x = new X(666);

    Another Question :
    In a browser, under global scope, it seems that we can access the real Variable Object (Global Object in this case) under the name window (I think that the virtual machine don’t give as acces to de Variable objects, only to copies in accessible objects like window or the referened by this). in a function context how can we direct access the Activation Object for discriminate between ActiveObject.a and this.a in my example above?

    Your example code:

    function foo(){}
    delete foo; // false (as expected)
    typeof foo; // “function” (as expected)

    /* now assign to a property explicitly */

    this.foo = 1; // erroneously clears DontDelete attribute
    delete foo; // true
    typeof foo; // “undefined”

    /* note that this doesn’t happen when assigning property implicitly */

    function bar(){}
    bar = 1;
    delete bar; // false
    typeof bar; // “number” (although assignment replaced property)

34. 

    André said on Jun 22, 2011 @ 9:31

    #54

    With that undefined thing lingering around, it is hard to imagine how it would be if it didn’t work the way you described.

    function() {
    delete blah;
    some_func(blah); // undefined or not?
    var blah;
    }

35. 

    Shay Ben Moshe said on Oct 17, 2011 @ 16:18

    #57

    Excellent article.
    I have learned a lot from it, thank you!

36. 

    Timothy Kay said on Dec 14, 2011 @ 10:17

    #59

    Your punchline is confusing:

    “Well, as I said before, Eval code has a special behavior when it comes to variable declaration. Variables declared within Eval code are actually created as properties without DontDelete.”

    The first time I read it, I parsed it this way, with the parsing shown using parentheses:

    “Well, as I said before, (Eval code has a special behavior when it comes to variable declaration. Variables declared within Eval code are actually created as properties without DontDelete).”

    I thought to myself, on the contrary, he didn’t say before that Eval code creates properties without DontDelete. It left me confused.

    What you meant to convey is this:

    “Well, (as I said before, Eval code has a special behavior when it comes to variable declaration). Variables declared within Eval code are actually created as properties without DontDelete.”

    You can make that clarification by adding a transition and some emphasis:

    “Well, as I said before, Eval code has a special behavior when it comes to variable declaration. But here’s the thing: Variables declared within Eval code are created as properties without DontDelete.“

37. 

    Sriram Krishnan said on Jan 20, 2012 @ 18:40

    #61

    Awesome Article ! kudos.

    var x = 1;

    /* Can’t delete, `x` has DontDelete */

    delete x; // false
    typeof x; // “number”

    eval(‘function x(){}’);

    /* `x` property now references function, and should have no DontDelete */

    In here the Eval is doing what is comparable to reassiging x (like x=2), so its attributes are not affected by that eval ! this is my understanding correct me if i am wrong

38. 

    Troy III said on Feb 14, 2012 @ 11:53

    #63

    cite: Firefox throw when trying to delete window.location. You can’t trust return values of delete either, when it comes to host objects; take a look at what happens in Firefox:
    /* “alert” is a direct property of `window` (if we were to believe `hasOwnProperty`) */
    window.hasOwnProperty(‘alert’); // true
    delete window.alert; // true
    typeof window.alert; // “function”
    
    -perhaps it’s a matter of FX version but: [attention] It is also possible that the >>document type<< of the page loaded on the current window has modified the behavior of the code being fed to console.
    My recent check shows that:
    On chrome ; latest firefox & IE9,
    window.hasOwnProperty('alert'); // (is) false, and correct.

    Safari however is returning true [which is incorrect], including Opera [which is correct].

    Safari’s return of “true” -is not true at all. In Safari the “alert” function is not a property of “window” either.
    That’s why deleting alert on window will yield true as it does for any other nonexistent window property- because it’s not there…
    Which means: Safari has a wrong implementation of hasOwnPrperty.
    So does Opera but in this case Opera speaks the truth and lat’s see why?

    The “alert” function in Opera is a property of “window” for a fact, and
    delete alert // true
    Is speaking the truth, since the
    alert //call will rise an >> error : 'undefined variable'
    Which means that the action is destructive and that the “alert” function will not be available for the rest of that session. Meaning that, in Opera you can delete the alert function since it is indeed a property of the actual window object. But that’s not the case with others.

    sumarum
    In all other mentioned browsers the “alert” function on “window object” is a property of window prototype, not the window itself. Therefore window.hasOwnProperty('alert') should return false in Safari too.

39. 

    Jeff said on Feb 26, 2012 @ 15:15

    #64

    Waaay too long.

40. 

    lb said on Mar 8, 2012 @ 17:46

    #65

    You do know this is one of my most favourite bookmarks on the internet, though I heard you’re on MS’s payroll now?

    What’s your view on DOJO’s AMD and declare API’s?

41. 

    Tamil Selvan said on Mar 13, 2012 @ 10:25

    #67

    (function(){ var x = 1; delete x; assertTrue(typeof x != ‘number’) })(); PASS ??
    How come this test passed?

42. 

    Sriram Krishnan said on Mar 13, 2012 @ 10:55

    #68

    @Tamil Selvan

    try this , it returns number

    (function(){ var x = 1; delete x; alert(typeof x) })();

43. 

    Tamil Selvan said on Mar 14, 2012 @ 0:18

    #69

    @Sriram Krishnan Ya it is true typeof x should be number but how come assertTrue(typeof x != ‘number’) Passed?
    I visited that test page mentioned in the tutorial from my Chrome browser. I have just pasted the output of the test.

44. 

    Mike said on May 3, 2012 @ 4:36

    #70

    Wow, one of the most important pieces of js literature I’ve ever read. Thanks.

45. 

    linus脱袜子 said on May 15, 2012 @ 4:13

    #71

    Through reading ‘The definitive guide of JavaScript’, I konw that JavaScript variables have a few attributes which may be involved with the delete operation, which are enumerable, configurable and writable, I haven’t see anything attribute named dontdelete, so, I wonder whether you just make this name up or is there any authortive references? More than glad to hear your answer, and indeed, your article is very inspiring, I’ve experiment the codes in rhino javascript shell hosted on Ubuntu, you’re totally right. Thank you again for your article and explanation, looking forward to communicate with you. Best regards.

46. 

    Animal said on May 16, 2012 @ 14:57

    #72

    Linus, from the ECMA standard:

    8.6.2.5 [ [Delete] ] ( P)
    When the [[Delete]] method of O is called with property name P, the following steps are taken:
    1. If O doesn’t have a property with name P, return true.
    2. If the property has the DontDelete attribute, return false.
    3. Remove the property with name P from O.
    4. Return true.

Trackbacks

1. Webdev Weekly #1 | samuli.hakoniemi.net said:

   [...] Understanding delete [...]

2. Interesting Finds: 2010 01.10 ~ 01.18 - gOODiDEA.NET said:

   [...] Understanding delete [...]

3. Perfection kills » Javascript quiz said:

   [...] else does it before me. Meanwhile, you can take a look at my articles on function expressions and delete operator, understanding which would help you answer some of these questions, and more importantly, explain [...]

4. Weekly Digest for February 11th – BorkWeb said:

   [...] Perfection kills » Understanding delete — 3:42pm via [...]

5. [译]理解删除 ­ army8735 said:

   [...] http://perfectionkills.com/understanding-delete/ [...]

6. links for 2010-03-30 « Daniel Harrison's Personal Blog said:

   [...] Perfection kills » Understanding delete (tags: javascript) Possibly related posts: (automatically generated)links for 2009-10-07links for 2009-04-08links for 2010-03-10Keep to the Script   Leave a Comment [...]

7. Publishing 5 books this year | Refresh said:

   [...] some excel­lent cri­tiques (of this oth­er­wise best­selling book!), such as this one by @kangax, which is the arti­cle that actu­ally prompted me to pitch a sec­ond edi­tion to the [...]

8. 转：理解javascript中的delete机制(1)  -  JavaScript在线教程 said:

   [...] 在javascript中，我们有时候要使用delete删除对象。但是，对于delete的一些细节我们未必尽知。昨天，看到kangax分析delete的文章，获益匪浅。本文将文章的精华部分翻译出来，与各位分享。 [...]

9. Variables vs. Properties in JavaScript « JavaScript, JavaScript said:

   [...] full details on delete as it applies to variables and properties check out this priceless article by kangax. He also explains why Firebug appears to let you delete a [...]

10. Understanding Undefined and preventing ReferenceErrors « JavaScript, JavaScript said:

    [...] undefined Angus Croll: Variables vs. properties in JavaScript Juriy Zaytsev (“kangax”): Understanding Delete Dmitry A. Soshnikov: ECMA-262-3 in detail. Chapter 2. Variable object. ECMA-262 5th Edition [...]

11. Perfection kills » Understanding delete « Data Warehouse in the Cloud said:

    [...] 22, 2010 CollectGarbage via perfectionkills.com Posted by dmoraschi Filed in Uncategorized Leave a Comment [...]

12. Publishing 5 books this year | phpied.com said:

    [...] some excellent critiques (of this otherwise bestselling book!), such as this one by @kangax, which is the article that actually prompted me to pitch a second edition to the [...]

13. Perfection kills » Global eval. What are the options? said:

    [...] side effect of executing code globally via eval is that function and variable declarations create deletable bindings (which is most likely an insignificant [...]

14. RegexHacks :: Blog » The Top 150 Web Development Highlights from 2010 said:

    [...] 90. Understanding Delete [...]

15. The Top 150 Web Development Highlights from 2010 | Programming Blog said:

    [...] 90. Understanding Delete [...]

16. The Top 150 Web Development Highlights from 2010 | Programming Blog said:

    [...] 90. Understanding Delete [...]

17. JavaScript中delete操作符 | Wang Jun's Blog said:

    [...] 参考：http://xo-tobacoo.javaeye.com/blog/346644http://xiaolele.javaeye.com/blog/682242http://perfectionkills.com/understanding-delete/ [...]

18. The Top 150 Web Development Highlights from 2010 « Web Development « blog.officinazerouno.it said:

    [...] 90. Understanding Delete [...]

19. [번역] 자바스크립트에서 변수와 프로퍼티의 차이 | Inside jQuery said:

    [...] 변수와 프로퍼티에 어떻게 적용되는지 에 대한 자세한 설명은 http://perfectionkills.com/understanding-delete/을 [...]

20. Cheatsheet: 2011 04.01 ~ 04.10 - gOODiDEA.NET said:

    [...] Understanding delete [...]

21. JavaScript Delete Keyword Troubles « Eric Leads – JavaScript Architect said:

    [...] Read Understanding Delete on PerfectionKills.com   No Comments [...]

22. Mozilla Hacks Weekly, September 15th 2011 ✩ Mozilla Hacks – the Web developer blog said:

    [...] Griffiths Understanding delete – Great article on delete in JS and ( at least in part ) on how developer tools can betray [...]

23. Do you know the javascript “Delete” operator? « Fabio Stawinski said:

    [...] interesting and almost nobody uses it: http://perfectionkills.com/understanding-delete/ Compartilhe:Like this:LikeBe the first to like this [...]

24. javascript里delete操作符什么时候能成功删除变量? - Leon's blog said:

    [...] 有时候却不掉成功删除的情况. 这篇Understanding delete牛文详细解释了, 为什么会这样, 什么样的变量能成功delete, [...]

25. My Stream | The Top 150 Web Development Highlights from 2010 | My Stream said:

    [...] 90. Understanding Delete [...]

26. Perfection kills » Understanding delete | Maanas Royy said:

    [...] Perfection kills » Understanding delete. Share this:TwitterFacebookDiggLike this:LikeBe the first to like this post. This entry was posted in Uncategorized by m4manas. Bookmark the permalink. [...]

Leave a Comment