proposal-class-fields
proposal-class-fields copied to clipboard
tc39
Document `this` bindings in the ReadMe ?
It's a bit hard to tell from the ReadMe what this will be bound to in a static or instance initializer. For instances it seems to be the object being created. For a static field, would it be the class prototype?
For a static field, it would be the constructor. It's all just as if they were in methods. I'll add something to the readme.
Great, that's what I was asking for.
On Thu, Oct 12, 2017, 12:35 PM Daniel Ehrenberg [email protected] wrote:
For a static field, it would be the constructor. It's all just as if they were in methods. I'll add something to the readme.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-class-fields/issues/46#issuecomment-336242982, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUAmfGXWOSPSIuVfUNtW38it1X7hM0uks5srmoIgaJpZM4P3f_W .
Just to be sure that I understand this correctly, this is about an example like this one, right?
I see that Babel (and also TypeScript) emit code that simply moves the this access into the constructor. I’m sure I can get used to it, but don’t find it immediately intuitive as it mixes lexical (bar) and dynamic (this) scope.
I understand that it’s technically not really different from the situation where the class property stores a closure that gets bound to the instance, but I do find it more intuitive that the binding of a closure can change rather than the binding inside the body of an object literal.
To be clear, I’m not necessarily advocating for changing this behaviour and have people override the constructor again to be be able to do this, but clarification in the documentation, as mentioned in above comments, would be much appreciated.
Apologies for my delay on updating the documentation.
Really, there are a ton of edge cases which TC39 has spent a lot of time refining, and this merits some strong documentation about all the details and the reasons why. This wouldn't be introductory documentation, like the README tries to be, but something more advanced for people who want to dig deeper.
Is anyone interested in working on this kind of documentation? If so, let's get in contact and we can go over these cases together. Writing more about class fields and how they are designed has been high on my personal TODO list for months, and it pains me that it keeps ending up getting pushed back due to other tasks. If someone wants to collaborate on this, it'd be a big help.