Classes are Expressions
raganwald.com
Classes are Expressions
1–10 of 46 posts
Re: Classes are Expressions
#2What about private functions? For now I just add `_` in front of their names, but the code would look so much cleaner if I had some kind of a `private` keyword.
Re: Classes are Expressions
#3What about private functions? For now I just add `_` in front of their names, but the code would look so much cleaner if I had some kind of a `private` keyword.
I don't see why this technique wouldn't also work for methods, especially with the addition of computed property names [1].
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: Classes are Expressions
#4What about private functions? For now I just add `_` in front of their names, but the code would look so much cleaner if I had some kind of a `private` keyword.
I don't see why this technique wouldn't also work for methods, especially with the addition of computed property names [1]. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This technique absolutely works for methods. And again, this shows the elegance of having simple features that compose, rather than building a monolithic OO system.
Re: Classes are Expressions
#5Earlier quoted context omitted.
I don't see why this technique wouldn't also work for methods, especially with the addition of computed property names [1]. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This technique absolutely works for methods. And again, this shows the elegance of having simple features that compose, rather than building a monolithic OO system.
In practice, that turns into far too many ways of defining classes in Javascript. There are at least four major approaches, and that was last year.
Re: Classes are Expressions
#6Earlier quoted context omitted.
I don't see why this technique wouldn't also work for methods, especially with the addition of computed property names [1]. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This technique absolutely works for methods. And again, this shows the elegance of having simple features that compose, rather than building a monolithic OO system.
Sure thing, but could you show an example? Let's say we want the `rename` function be private, this is what I came up with: https://gist.github.com/ravicious/5412eebf8a1934ec7886
I don't particularly like this solution, because now I can't just write `this.rename()` in other Person functions. That's why I'd rather have a baked-in way to define private properties & functions instead of having to use (in my opinion) this weird syntax and later explain the whys and hows to other developers.
Re: Classes are Expressions
#7This is cool, could this behavior be mimicked by doing:
var name = 'name_' + Math.random() ; //assumed uniquenessRe: Classes are Expressions
#8This is cool, could this behavior be mimicked by doing: var name = 'name_' + Math.random() ; //assumed uniqueness
Yes, but you'll also want to use Object.defineProperty to ensure that the property is not enumerable.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Symbol tosses that in "for free."
Re: Classes are Expressions
#9Earlier quoted context omitted.
This technique absolutely works for methods. And again, this shows the elegance of having simple features that compose, rather than building a monolithic OO system.
Sure thing, but could you show an example? Let's say we want the `rename` function be private, this is what I came up with: https://gist.github.com/ravicious/5412eebf8a1934ec7886 I don't particularly like this solution, because now I can't just write `this.rename()` in other Person functions. That's why I'd rather have a baked-in way to define private properties & functions instead of having to use (in my opinion) th…
Writing this[rename](...) instead of this.rename(...) is hardly onerous.
Your solution mostly works, but a simpler one takes advantage of combining computed property keys and compact method syntax:
Re: Classes are Expressions
#10Earlier quoted context omitted.
This technique absolutely works for methods. And again, this shows the elegance of having simple features that compose, rather than building a monolithic OO system.
In practice, that turns into far too many ways of defining classes in Javascript. There are at least four major approaches, and that was last year.
If you want something that isn't in the language, you build it yourself. If what you build becomes popular, in the fullness of time it gets built into the language as a full feature or as syntactic sugar. That's exactly how we got the class keyword, modules, everything.
But if you choose the wrong thing, one day your choice is obsolete. That is a risk, and it's prudent consider the consequences carefully.
If that troubles you, by all means write your code without any encapsulation, and wait for the language to acquire the feature in a few years. In the mean time, your code base will grow without that kind of encapsulation. Only you can determine whether this is a bad thing or not. YMMV, and all that.
This is a very common problem to ponder, we end up arguing about whether you should be an early adopter, a main streeter, or a laggard.
But really, the post isn't a screed in favour of using private properties, it's a suggestion that making classes out of first-class values in the language gives us the flexibility to build whatever we think we need.
Private properties is a particularly simple example. Traits and mixins are also useful, but would take even more space to articulate. But the general point is still that making new things ("classes") out of the existing materials ("functions and prototypes") is a win in general.