Re: Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

Yulia Startsev yulia at mozilla.com
Sun Mar 10 13:38:58 UTC 2019


I was asked by John to chime in, and I will repeat here what I sent to him
directly via email.

Thanks for making the proposal and thinking through this problem. Indeed,
`this` is a confusing concept for many people, and is an existing baggage
from early JavaScript Design.

This having been said, it isn't clear to me what you are proposing. Your
proposal is already possible in JavaScript as is, it is not adding a new
capability to the language, it is instead introducing syntax as a work
around that has already been extensively tooled. So, knowing this, how do
we approach this problem? People are definitely struggling with this issue,
so how can we do it better?

Let's play with this problem a bit. From your proposal it looks like you
want a way to clearly identify methods on a class to have access to the
`this` that is the class instance. At the moment, as you mention, you have
to bind it in the constructor. What if it was a list of "bound methods"? or
a keyword at the beginning of the class declaration called bound.

```
class Xyz {
  boundMethods = ["counter"];
   constructor() {
    this.count = 0;
    // something
  }

  counter() {
    this.count++;
  }

  render() {
  // some code
  element.addEventListener("click", this.counter);
  }
}
```

Well, that looks a bit ugly, and I can imagine a class having a lot of
these and it not being much better than what we had before. Plus, it isn't
clear to a programmer what is going on here. Let's try something else

What if we had a keyword like `async`?

```

class Xyz {
  constructor() {
    this.count = 0;
    // something
  }

  bound counter() {
    this.count++;
  }

  render() {
  // some code
  element.addEventListener("click", this.counter);
  }
}

```

You get the idea. So this is another way to think about the problem. But if
we do this, then suddenly, we are going to be adding a huge list of
keywords to the beginning! imaging `bound async nameOfFunction()`, and also
how do you know what order they should be in?. So maybe there is another
solution? Maybe someone has tried something before.

If we go through the current proposals that are in flight at the TC39,
there is a proposal that also tries to tackle this, the decorators
proposal. Take a look at how decorators solves the same problem:
https://github.com/tc39/proposal-decorators#decorators

here is how it is done there (simplified, only showing `@bound` at work):

```

class Counter extends HTMLElement {
  _x = 0;

  @bound
  _clicked() {
    this._x++;
  }

  constructor() {
    super();
    this.onClick = this._clicked; // this is a private method, see the
proposal for more details
  }

  connectedCallback() { this.render(); }

  render() {

    // ... it does something, lets imagine creates an element that
listens for a click

    element.addEventListener("click", this.onClick)

  }
}

```

I removed some of the complexity of the original example, to help make it
clear what is going on here in relation to what you were suggesting. The
way it works is @bound makes clicked into an auto-bound method, replacing
the explicit bind call later. You can read more about this in the proposal
I linked. This is one way to address the issue that you bring up, without
introducing a new keyword `self`.

It might be worth looking through some previous proposals to get a sense of
how others have tried to tackle the problem. For the decorators proposal,
it is really just a starting point -- you might find other points of
reference. See if it is what you were looking for. If it doesn't fully
address the case, it might point you in a direction that gets closer to a
proposal, or it might bring up other interesting questions. We don't have
to start with a fully formed solution -- collecting problems and
constraints is an interesting way to work.

Hopefully this helps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190310/af7845fd/attachment.html>


More information about the es-discuss mailing list