Replacing ‘that = this’ assignments in JavaScript with Arrow Functions

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by spankalee on Friday April 14, 2017 @03:37PM (#14116647)

Unfortunately, there are several problems with this approach:

1) You're creating a new function instance for `SomeClass.method` every single time you create an instance of SomeClass. This will slow down construction.

2) `method` is an instance property, not a prototype property, and so takes up more memory for a reference per instance, plus the memory of the function instance.

3) In that function instance, you're closing over the references to `someClass` and `arg1` even though they're already available in `method` as `this` and `this.arg1`, also increasing the memory of instances.

4) Setting method will cause an unnecessary hidden-class transition.

If you really want to hide `secretArg`, use a WeakMap:

    const secrets = new WeakMap();
    class SomeClass {

      constructor(arg1, secretArg) {
        this.arg1 = arg1;
        this.bar = undefined;
        secrets.set(this, secretArg);
      }

      method(foo) {
        this.bar = foo;
        const secret = secrets.get(this);
        secret.count++;
      }
    }

This will result in much lighter weight instances.

[ Parent | on HN ]

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by andrewstuart2 on Friday April 14, 2017 @03:57PM (#14116797)

I understand there are some runtime implications but the vast majority of the "classes" created in my applications are instantiated once or only at startup. The memory usage and speed implications are negligible compared to the added maintainability.

In the grand scheme of all the allocation and computation taking place in my applications, these concerns are very far down the line.

Now, if you happen to be creating an application or framework that for some reason has to do a whole lot of allocating and might be meaningfully and measurably affected by such issues, then by all means use prototype "methods" when it will make a difference.

Personally, code clarity is much more important than making sure my application starts microseconds faster and allocates several bytes fewer per instance when there are only going to be ~10s of instances ever created.

[ Parent | on HN ]

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by vmasto on Friday April 14, 2017 @04:23PM (#14116997)

As long as we are extremely clear of the implications it's a good enough reasoning.

Many people, especially newcomers, believe that just because their code initializes a class only N times it's being instanced exactly N times. This is false more often than not, especially in server environments.

[ Parent | on HN ]

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by orf on Friday April 14, 2017 @06:18PM (#14117869)

> code clarity

This makes sense if it's only you working on a project, but it would be pretty confusing and weird for someone new to join.

[ Parent | on HN ]

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by andrewstuart2 on Friday April 14, 2017 @06:19PM (#14117874)

What would be confusing and weird?

[ Parent | on HN ]

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by orf on Friday April 14, 2017 @06:38PM (#14117967)

It being done nowhere else? Muscle memory? It looking non-standard and harder to parse?

[ Parent | on HN ]

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by acjohnson55 on Friday April 14, 2017 @05:35PM (#14117635)

I'd argue that adhering workaround for things that have language-level solutions nowadays hurts code clarity, if other people have to work with your code. Sure, the non-functional noise fades to the background when you're used to the pattern, but ES6 has been out for a while now, and it provides reasonable solutions.

[ Parent | on HN ]

Re:Replacing ‘that = this’ assignments in JavaScript with Ar... by andrewstuart2 on Friday April 14, 2017 @06:31PM (#14117926)

Unless javascript removes alternate meanings of `this`, which will never happen, it does not have a language-level solution. In fact, I think it's easily as reasonable a solution as lambdas. I may be biased because I think ES6 is a hot mess, but the lack of `this` binding of lambdas is a serious misstep IMO.

If anything, ES6 lambdas add yet another way of interpreting `this` because while it is a function, it's not functionally scoped. Even better, a lambda is a function but `call` and `apply` are interpreted differently [1] since `this` is not bound. If you ever need to use `call` or `apply`, you'll have to know exactly how the called code is implemented to avoid bugs.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[ Parent | on HN ]