When I use classes, when I don’t, what I do instead and why

Also, if you only use arrow functions you don't even have that problem.

Nonsense. It's not a question of whether you understand `this` or not, it's a question of whether thinking about the different cases of `this` is really a good use of your time. Alternately: `this` is poorly designed and gets in your way.

Here's an example of a recent production bug:

  async.timeout(server.close, 60000)(exit)

And one way to fix:

  async.timeout(cb => server.close(cb), 60000)(exit)

In case the problem is non-obvious (that's the point!), the first line loses the binding to the specific `server` in question. Lovely. `this` in JS forces the consumer of a module (in this case `server`) to have knowledge of how the module represents its state in order to use it. That's not a good pattern.

The more I learn JS the more I am worried that I am not using 'this' right.

I swap back and forth between javascript/python and with JS it always feels like I am one step away from disaster if I accidentally forget to bind this.

The Gambit he's claiming is straightforward. Given type X, calling object of type X, a's method a.doit() is just sugar on the fundamental doit(a). The way you get the former is to introduce JS concept of _this_ which is accidental complexity that doesn't pull its weight. I tend to agree.

Do arrow functions get added to the prototype or the instance of the object? Can they be created directly in the class body or have to be added inside the class constructor?

Agreed - I don't find the usage of "this" to have any cognitive load, as long as arrow functions are used everywhere. "Arrow functions only" isn't a tough standard to maintain.

I don't know why, but just by reading the title my mind implied JavaScript, and I noticed it doesn't have that word only after reading your comment.

Weird.

I actually have to maintain a js codebase that uses a generic “addProperty” function at its core to generate getters and setters. It is terrible to debug. Properly encapsulated class methods are much easier to read and debug.

This problem has been solved for a long time. Some data doesn’t need a class, but when it does, don’t roll your own.

What do you mean by ADTs introduce unnecessary coupling of information? ADTs allow you to clarify and safely handle otherwise vague data. Maybe I'm misunderstanding, but your comment reads to me like you're in support of stringly typed programming.

It's not clear to me what you mean by the power of dynamic languages. I'm inclined to think your perspective on static languages is limited to C# or some other OOP static languages. In particular, your example doesn't seem very novel for a statically typed language. Heck, I just built a reasonably elegant parser framework in Go and it doesn't even have generics. This makes me wonder if you're not attributing your OOP frustrations to static typing.

This is in fact what classes are.

That book was written in 2008. JavaScript classes were introduced with ECMASCRIPT 2015.

> In naive OO examples (Animal -> Cat) it does.

An inheritance hierarchy consists of three things: a taxonomy, behavioural inheritance and structural inheritance. The first is only useful on occasion, and the last two don't even apply to Animal → Cat; "animal" is not a behavioural constraint, and a cat certainly doesn't have a platonic ideal of an animal hidden somewhere inside its gut.

Since classes are just sugar over prototypes, their performance is just about the same for instantiation. I assume the article is comparing them to functions that return an object literal with methods.

Here is a simple example of equivalent code in a class, function with a closure, and a prototype:

  class FooClass {
    constructor (bar) { this.bar = bar; }
    getBar () { return this.bar; }
    setBar (bar) { this.bar = bar; }
  }

  function FooClosure (bar) {
    var _bar = bar;
    return {
      getBar () { return _bar; },
      setBar (bar) { _bar = bar; }
    };
  }

  function FooPrototype (bar) { this.bar = bar; }
  FooPrototype.prototype.getBar = function () { return this.bar; };
  FooPrototype.prototype.setBar = function (bar) { this.bar = bar; };

When instantiating a lot of objects, the prototype and class are practically the same, but the function closure pattern is a lot slower. On my machine, instantiating one hundred million of the class or prototype each took about 500ms, but the closure function took about 3s.

No sane language makes you write person1 person2 person3. Immutability doesn't mean you can't reuse names; only that the reassignment is in lexical scope, and doesn't impact any other references to what you saw as person1.

That'd be awesome. Submit a proposal! https://github.com/tc39/proposals

Interesting, that would mean you would have confusion if someone used your class like:

foo.bar.bind(somethingElse);

How would the callee know that this would potentially conflict?

Already exists.

    class Foo {
      bar = () => {
        console.log(this);
      }
    }

Has to be compiled with Babel, though.

There's already a proposal for field declarations, where you can do the following:

  class Foo {
    bar = () => {
      console.log(this);
    }
  }

This basically puts `this.bar = () => console.log(this)` in the constructor, and since it's an arrow function it captures the correct context.

See https://github.com/tc39/proposal-class-fields.

Yeah, if you can't grasp 'this', good luck figuring out delegates. (Note: Some/many languages call these "Closures") 'this' is just a context pointer.

classes don't actually store their functions (except virtual ones).

    class A{ 
        int data; 
        void method1(int input){data = input;}
        }
    A my_instance;

is actually

    struct A {int data;}
    method1_for_struct_A(A *context, int input){ context->data = input; } //normal local function
    A my_instance;

and this:

    my_instance.method1(3);

becomes this:

    method1_for_struct_A(my_instance, 3); 
    //send a pointer to the class we're operating on

And once you understand that, delegates are easy, because they're just... sending the context pointer around. So in D:

    //note: global function, NOT apart of any class.
    delegate void my_function(int input)
        {
        data = input; //where is data coming from?
       // the surrounding context.
        }

    void my_test_function()
        {
        int data = 2;
        my_function(3); // is a delegate and gets implicitly sent the context 
        //pointer for my_test_function, and now, it can access data.
        // Note this is a RUN-TIME adjustable function. Delegates can be passed
        // around. 
        }

and internally my_function is actually (note the pattern):

    void my_function(context_pointer, int input)
        {
        context_pointer.data = input;
        }

and the compiler implicitly sends the context with it:

    my_function(3) becomes
    my_function(my_test_function_context, 3);

So basically, delegates are just an extension of what classes already use under-the-hood. Delegates are "fat" function pointers. Function pointers point to a function, and the "fat" pointer includes an additional "context" pointer to the surrounding data frame so you can dereference it to access the surrounding data. You can do all of this in plain C if you don't mind writing all the boilerplate code yourself.

Virtual functions are similar to delegates. The class actually contains the function pointer / delegate instead of re-writing it at compile-time. Which allows them to be overridden at run-time. Whereas "this" usually means you can figure it out statically, at compile-time, so the function call is a pure function call and doesn't incur the penalty of looking up a pointer for the virtual call.

I bet I'm probably missing something or slightly off here or there, so someone feel free to chime in and correct me. Consider the code pseudo-code. I might have flipped something from memory.

It's not that simple. You've mentioned only one of the possible meanings of `this`: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

In the global execution context (outside of any function), this refers to the global object whether in strict mode or not.

    // In web browsers, the window object is also the global object:
    console.log(this === window); // true

    a = 37;
    console.log(window.a); // 37

    this.b = "MDN";
    console.log(window.b)  // "MDN"
    console.log(b)         // "MDN"

Inside a function, the value of this depends on how the function is called.

== Simple call ==

Since the following code is not in strict mode, and because the value of this is not set by the call, this will default to the global object, which is "window" in a browser.

   function f1() {
      return this;
    }
    
    // In a browser:
    f1() === window; // true 
    
    // In Node:
    f1() === global; // true

In strict mode, however, the value of this remains at whatever it was set to when entering the execution context, so, in the following case, this will default to undefined:

    function f2() {
      'use strict'; // see strict mode
      return this;
    }
    
    f2() === undefined; // true

So, in strict mode, if this was not defined by the execution context, it remains undefined.

== The bind method ==

ECMAScript 5 introduced Function.prototype.bind. Calling f.bind(someObject) creates a new function with the same body and scope as f, but where this occurs in the original function, in the new function it is permanently bound to the first argument of bind, regardless of how the function is being used.

    function f() {
      return this.a;
    }
    
    var g = f.bind({a: 'azerty'});
    console.log(g()); // azerty
    
    var h = g.bind({a: 'yoo'}); // bind only works once!
    console.log(h()); // azerty

== Arrow functions ==

In arrow functions, this retains the value of the enclosing lexical context's this. In global code, it will be set to the global object:

    var globalObject = this;
    var foo = (() => this);
    console.log(foo() === globalObject); // true

Note: if thisArg is passed to call, bind, or apply on invocation of an arrow function it will be ignored. You can still prepend arguments to the call, but the first argument (thisArg) should be set to null.

No matter what, foo's this is set to what it was when it was created. The same applies for arrow functions created inside other functions: their this remains that of the enclosing lexical context.

== As an object method ==

When a function is called as a method of an object, its this is set to the object the method is called on.

In the following example, when o.f() is invoked, inside the function this is bound to the o object.

    var o = {
      prop: 37,
      f: function() {
        return this.prop;
      }
    };
    
    console.log(o.f()); // 37

Note that this behavior is not at all affected by how or where the function was defined. In the previous example, we defined the function inline as the f member during the definition of o. However, we could have just as easily defined the function first and later attached it to o.f. Doing so results in the same behavior:

    var o = {prop: 37};
    
    function independent() {
      return this.prop;
    }
    
    o.f = independent;
    
    console.log(o.f()); // 37

This demonstrates that it matters only that the function was invoked from the f member of o.

Similarly, the this binding is only affected by the most immediate member reference. In the following example, when we invoke the function, we call it as a method g of the object o.b. This time during execution, this inside the function will refer to o.b. The fact that the object is itself a member of o has no consequence; the most immediate reference is all that matters.

== "this" on the object's prototype chain ==

The same notion holds true for methods defined somewhere on the object's prototype chain. If the method is on an object's prototype chain, this refers to the object the method was called on, as if the method were on the object.

== "this" with a getter or setter ==

Again, the same notion holds true when a function is invoked from a getter or a setter. A function used as getter or setter has its this bound to the object from which the property is being set or gotten.

== As a constructor ==

When a function is used as a constructor (with the new keyword), its this is bound to the new object being constructed.

While the default for a constructor is to return the object referenced by this, it can instead return some other object (if the return value isn't an object, then the this object is returned).

== As a DOM event handler ==

When a function is used as an event handler, its this is set to the element the event fired from (some browsers do not follow this convention for listeners added dynamically with methods other than addEventListener).

== In an in–line event handler ==

When code is called from an in–line on-event handler, its this is set to the DOM element on which the listener is placed:

    <button onclick="alert(this.tagName.toLowerCase());">
      Show this
    </button>

The above alert shows button. Note however that only the outer code has its this set this way:

    <button onclick="alert((function() { return this; })());">
      Show inner this
    </button>

In this case, the inner function's this isn't set so it returns the global/window object (i.e. the default object in non–strict mode where this isn't set by the call).

> No it isn't. Its a function argument that is implicitly passed "left of the dot".

That is true in JavaScript, but not in other languages that also have "this" and closures. So the confusion comes from two issues: 1. JavaScript is inconsistent with other languages, and 2. It's not at all clear that JavaScript's semantics are actually good.

In other languages where "this" is not loosely bound, there is next-to-no confusion around them and no problems, so the evidence is there that the semantics JavaScript chose aren't user-friendly.

The reason JS has those semantics is because it (at the time) had no way to distinguish between a method declaration (where this should be dynamically bound) and a function declaration (where this should be lexically bound). Other languages with class syntax don't have that problem.

JavaScript does have class syntax now, but changing the semantics of how this works would have been very difficult this many years later.

Crockford says he doesn't use `this` and classes were the worst thing that could have been added to JavaScript.

Yeah I was just thinking, why can't javascript be easy and simple like C++?