3 ms·

> I don't get the relucatance to use the language's features rather than hacks Symbol is a language feature. As is accessing a property with `[` and `]`. Using

> I don't get the relucatance to use the language's features rather than hacks Symbol is a language feature. As is accessing a property with `[` and `]`. Using the language's features as they were designed is not a hack. And I think we may see your browser's tooling improve when it natively supports ECMAScript 2015, instead of whatever is transpiled today. Now: Why do you think that properties named by symbols have this special property of being non-enumerable by default? Do you think it is just a coïncidence that it is useful for making a pseudo-private property? I do not think this particular pattern is a "hack," I think it is one of the use cases that were considered when designing symbols in the first place. But returning to the purpose of the article, whatever you or I may think of the performance of using closures to create private data, your pattern again supports the article's thesis: By making classes out of functions, objects, and prototypes, we can use the features of the language to extend a class's semantics. If there was a full-featured monolithic class system like Ruby, we might find that the scoping for methods is not like the scoping for lambdas, and thus we can't just use a closure when we want one. Your proposed solution leverages the exact same property of JavaScript as TFA.

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 ago
  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.

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 ago
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.