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

Michael Luder-Rosefield rosyatrandom at gmail.com
Sun Mar 10 06:57:20 UTC 2019


How about binding `this` to a variable in the constructor? The following
syntax throws an error due to `this` being a reserved word, so won't break
any existing code:

```
class Foo {
  constructor (this: self, /* normal args */) {
    // ...
  }
}
```

I can see arguments against that as it breaks the convention for how
parameter lists work, and also requires a constructor. Perhaps, then, we
could either use something like a modified version of class field
declarations to make class variables:

```
class Foo {
  const self = this;
  // ...
}
```

Or, maybe, allow parentheses before the class body to define variables:

```
class Foo (this: self) {
  //...
}
```

No, I don't like that one either.

The second suggestion (class variables as extension of class fields
proposal) seems like it has potential to me, so it seems like an excellent
time for everyone here to tell me why it's awful and stupid.

On Sun, 10 Mar 2019 at 06:59 Jordan Harband <ljharb at gmail.com> wrote:

> The engine only has that knowledge when you call it in `a.b()` form - at
> which point, `this` is already the instance. For a keyword to not be
> context dependent, it'd have to be the instance even when you'd done
> something like `const { b } = a; b()`. To do this would require either a)
> `a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
> a getter that does that binding upon request.
>
> Constructor-binding, field-binding, or arrow function fields all work the
> same way - they create a separate copy of a function for *each and every*
> instance, so that the function can point back to the instance even when
> extracted off of the object.
>
> I'm not clear on how there'd be any other way to do it.
>
> On Sat, Mar 9, 2019 at 1:41 PM john larson <johnlarsondev1 at gmail.com>
> wrote:
>
>> Although the method lives on the prototype, the engine should already
>> have knowledge of the object whose method is being invoked. I am not an
>> expert on the internal workings of the engine, so I would be glad if anyone
>> would correct me on this if I am wrong.
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>> <#m_6849901573705770350_m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband <ljharb at gmail.com> wrote:
>>
>>> An additional keyword like this would require a function to have a
>>> hidden reference back to the instance. However, especially for `class`
>>> methods, but also for ES5-style inheritance, or even for `class Foo {}
>>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
>>> billion instances, but only one function that uses your new keyword - how
>>> would the engine know which instance you were referring to?
>>>
>>> On Sat, Mar 9, 2019 at 7:50 AM Bergi <a.d.bergi at web.de> wrote:
>>>
>>>> Hi John,
>>>>
>>>> > I believe that it would be a trivial task for
>>>> > current static code analyzers to restrict usage of "this" for anyone
>>>> > opting in to use this new keyword exclusively.
>>>>
>>>> Static tooling, like the TypeScript compiler, can detect problematic
>>>> method usage already today. Sure, having a dedicated syntax for this
>>>> will make static analysis simpler, but I don't deem that a worthy
>>>> addition to the language.
>>>>
>>>> > As you mentioned, arrow functions might have their own
>>>> > problems. Wouldn't such an alternative keyword be a good addition to
>>>> our
>>>> > toolkit anyway?
>>>>
>>>> What I was trying to say is that your proposed alternative has exactly
>>>> the same problems as instance-member arrow functions have today.
>>>>
>>>> Best regards,
>>>>   Bergi
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190310/04fb4af4/attachment.html>


More information about the es-discuss mailing list