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

Jordan Harband ljharb at gmail.com
Sun Mar 10 07:10:42 UTC 2019


There'd still have to be a way for an arbitrary function - which (unless
called in `a.b()` form) has no guaranteed connection back to `a` - to have
a reference back to the object.

On Sat, Mar 9, 2019 at 10:57 PM Michael Luder-Rosefield <
rosyatrandom at gmail.com> wrote:

> 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_4773041203224270933_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/20190309/e6467f86/attachment-0001.html>


More information about the es-discuss mailing list