6 ms·
Er, to be clear, your example uses a closure. Your real question is, can this be done without `Symbol`? And it can, since the symbol is just a secret stored in
by Cushman 11y ago
Er, to be clear, your example uses a closure. Your real question is, can this be done without `Symbol`?
And it can, since the symbol is just a secret stored in a closure and there are other sorts of secrets. Aside from the "Math.random() + {enumerable: false}" suggestion found elsewhere, you can reproduce the precise[0] semantics of your example using something like:
// Please do not actually write code like this
var Person = (function() {
var names = [];
function Person(name) {
this.key = names.length;
names[this.key] = name;
}
Person.prototype.sameName = function(other) {
return names[other.key] === names[this.key];
};
return Person;
})();
Which is the ES3 generated by this CoffeeScript:
class Person
names = []
constructor: (name)->
@key = names.length
names[@key] = name
sameName: (other)->
names[other.key] is names[@key]
Of course these implementations do something dramatically different behind the scenes, and I emphatically don't think people should follow this example, but the interface is the same. Edit: Except that I left `.key` as an editable property, which is problematic. We'll leave that bit as an exercise, though.
Whether `names[this.key]` is as "nice" to work with as `this[nameKey]` is, uh, left up to the reader; personally, count me in the camp that doing either of those things is nuttypants compared to `this._name`.
[0]: Assuming that `otherPerson` in your constructor is a typo, of course ;P
- munificent 11y ago> [0]: Assuming that `otherPerson` in your constructor is a typo, of course ;P Oops, yup. Fixed. Your solution is pretty clever, though it leaks memory like a sieve. To get around that, you end up needing something like weak maps. Once you have those, when you do the pattern you suggest, you are basically doing metaprogramming and reinventing the very idea of an "object" yourself from scratch. That can be fun to do, but to me it starts to feel less like expressing "the same thing" and more like implementing a new language that lets you express the same thing. Just because I can implement a GC in C, that doesn't mean C has a GC. :)
- Cushman 11y agoIn ES3 you'd need destructors, I think. But yes, agreed on all points :) And yet-- is the Symbol approach not metaprogramming? It's clearly a much saner way to shoehorn this feature in, but it's still a shoehorn. And the underlying magic in both cases is in fact simple closure scope, which is really what I wanted to demonstrate. Edit: And I guess my broader point, to make this more constructive, is that in JS these kinds of idioms live on a continuum of metaprogramming, and for the sanity of your co-contributors you usually want to be doing as little of that as necessary. Like others, I'm wary of presenting something like your example as a "design pattern" without that context. Edit 2: To illustrate what I mean, I swear to you that if this pattern is adopted widely you will find code like this in the wild: ... = > { let accountNumberKey = Symbol('accountNumber'); return class Account { constructor (accountNumber) { this[accountNumberKey] = accountNumber; this.accountNumberKey = accountNumberKey; // ??? but transaction log works now ...