4 ms·
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
by greggman 11y ago
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.
- braythwayt 11y agoIf 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.