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 < [email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
