Darien Maillet Valentine

This comes to mind as something I think is pretty weird, if I’m understanding the proposal correctly... ### module-a ``` export const foo = { bar() { /*...*/ } };...

That makes more sense to me, I think that’s a lot safer and simpler, and realm-level globalness isn’t actually solving anything I think; 99% of the time, the event handler...

‘Autobinding’ instance methods is probably better understood as functionality covered by [the class ‘fields’ proposal](https://tc39.github.io/proposal-class-public-fields/). I think one could argue that in either form, this is kind of an antipattern...

Autobinding on instantiation is a severe code smell. Decorators make it, and lots of other things, declaratively possible, but I really don’t believe it should be codified into the language...

Sorry, rektide. You can code however you like; however, on forums where people are discussing new syntax and language constructs I think it is reasonable for people to state their...

@simevidas Sure, and as a userland solution this is cool and generally won’t lead to problems. (Not sure what you mean by array function though.) derp arrow of course 👍...

@Alxandr be careful ... I got yelled at 😅 Though `this` resolution was always a point of confusion for folks coming from other languages, I think this particular set of...

Interesting, Alxandr, I hadn’t realized that.

A (perhaps?) interesting sidebar to Alxandr’s explanation: the function returned by `Function.prototype.bind` is an [exotic object](https://tc39.github.io/ecma262/#sec-bound-function-exotic-objects) which has a unique record that references the original function & fixed context /...

That’s true — using `.bind` or arrow functions for this is pretty unlikely to lead to performance issues speed-wise in any case, and would only lead to performance issues memory-wise...