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

Jordan Harband ljharb at
Sat Mar 9 21:59:02 UTC 2019

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> 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.
> <> Virus-free.
> <>
> <#m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband <ljharb at> 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 {}
>> = 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list