Classes are Expressions

Re:Classes are Expressions by greggman on Thursday June 04, 2015 @11:24PM (#9663735)

I guess I don't see obfusticating my own code as a good pattern. I gave the debugging example. Similarly serialization? With the closure solution I just do

    var Person = function(first, last) {
      var serializable = {
        first: first,
        last: last,
      };
      ...

With Symbol? I guess I just don't see making things more complicated as a positive pattern.

[ Parent | on HN ]

Re:Classes are Expressions by braythwayt on Thursday June 04, 2015 @11:59PM (#9663829)

If you consider the use of symbols as “obfuscating your own code," use closures with my blessing.

What, exactly, is the problem here? I don’t recall the article saying that symbols are the only way to do this, or the best way to do this out of all the options. I recall people saying similar things about closures for a while, until it caught on that closures and lexical scope are a natural part of JavaScript.

TFA’s point is that ECMAScript 2015’s choice to keep classes as first-class functions with prototypes that are objects is what allows us to use all of the techniques we already have for first-class values, including returning them from functions.

As I keep saying, using a closure (if that’s what you want to do) demonstrates the exact same thing, it works because a method is just a function.

Now that we have established that I am not claiming that symbols are better than closures, I will warn you about an edge case: When you use compact method syntax, you do get something that an ordinary function does not provide, the `super` keyword.

I do not know how to make that work in the case where you assign a function to an instance of an object. So if you want to override a function while calling the super-class’s implementation, it might be tricky to use the closure solution.

That being said... I wouldn’t stay up late worrying about it.

[ Parent | on HN ]