Classes are Expressions • Hacker News Board

Re: Classes are Expressions

#11

Post by mikegerwitz » Thu, Jun 04, 2015, 6:54 PM UTC

ravicious wrote: post #6

braythwayt wrote: post #4

Earlier 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…

You wouldn't be able to simply; the same issues exist as in ES3 in this regard.

(I wrote about them extensively years back here: http://mikegerwitz.com/papers/coope/coope.pdf.)

Re: Classes are Expressions

#12

Post by ravicious » Thu, Jun 04, 2015, 7:04 PM UTC

braythwayt wrote: post #9

ravicious wrote: post #6

Earlier quoted context omitted.

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: https://gist.github.com/raganwald/18f8c179101cfd93c291

Okay, now this certainly feels better than my example and is much more bulletproof than prefixing function names with `_`, thanks.

Re: Classes are Expressions

#13

Post by greggman » Thu, Jun 04, 2015, 7:15 PM UTC

I guess I need to be schooled by why not just use closures?

    var Person = function(first last) {
      this.fullName = function() {
        return first + " " + last;
      };
      this.rename = function(newFirst, newLast) {
        first = newFirst;
        last = newLast;
      };
    };

Problem solved, you can't access `first` and `last` outside the class. You might retort "they're bigger" or something but just like everything else in JS they just need the right people to concentrate on them and they'll likely get optimized.

I don't get the relucatance to use the language's features rather than hacks (using naming standards and compilers to obfusticate names and then cross fingers) or other hacks (Symbol). Really? You Really want me to write code using Symbol? That's going to be awesome in the debugger. Let's add a watch to "weke30o304_first". Refresh, of shit it's now "gtgrf40r3fe_first", my watches all broke (T_T)

It also makes me sad the `class` spec didn't take that into account so you could use a closure with a `class`.

Re: Classes are Expressions

#14

Post by braythwayt » Thu, Jun 04, 2015, 7:30 PM UTC

greggman wrote: post #13

I guess I need to be schooled by why not just use closures? var Person = function(first last) { this.fullName = function() { return first + " " + last; }; this.rename = function(newFirst, newLast) { first = newFirst; last = newLast; }; }; Problem solved, you can't access `first` and `last` outside the class. You might retort "they're bigger" or something but just like everything else in JS they just need the right pe…

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

Re: Classes are Expressions

#15

Post by spankalee » Thu, Jun 04, 2015, 7:38 PM UTC

I know this might be an unpopular view here, but declarative(ish) constructs like class give a little hope that programs will be more statically analyzable so that we can get nice things like static type checking and warnings, code completion, optimizing compilers, etc.

These types of imperative patterns make life extremely hard on tools, which now need to add in unreliable things like escape analysis to be able determine which classes are visible. Modules will help a little with explicit exports, so that the importing modules have some hope of tooling, but analysis within a module would suffer.

Re: Classes are Expressions

#16

Post by keithwhor » Thu, Jun 04, 2015, 7:38 PM UTC

Just looks like more JavaScript antipatterns, this time with some ES6 flavour.

We know how to "solve" the problem of encapsulation with JavaScript. It's not with closures, Symbols, or some other arbitrary hack. We do it by enforcing specific idioms that only require a developer to recognize intent instead of learning 80 different ways to do the same thing. You simply put a single or double underscore in front of the property name.

I read what I thought was a clever anecdote by another developer the other day, that the underscore in "obj._varname" indicates "here be dragons." It's an extremely simple idiom to teach new JavaScript developers.

I get it, JavaScript is robust. So you can do fun things like this! These are great experiments. But really, what are you accomplishing? You've now just thrown in a closure and a bunch of lines of code (defining your symbols, etc.) that any developer new to your codebase is going to look at like "... what the... what is going on here?" You can solve the problem easily with one character.

Consistency. Convention. Creating useful, easy-to-understand, repeatable idioms. That's what we should be focusing on.

Re: Classes are Expressions

#17

Post by rmrfrmrf » Thu, Jun 04, 2015, 7:44 PM UTC

Animats wrote: post #5

braythwayt wrote: post #4

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

That's part of why I think CoffeeScript isn't going anywhere anytime soon.

Re: Classes are Expressions

#18

Post by [deleted] » Thu, Jun 04, 2015, 8:19 PM UTC

greggman wrote: post #13

I guess I need to be schooled by why not just use closures? var Person = function(first last) { this.fullName = function() { return first + " " + last; }; this.rename = function(newFirst, newLast) { first = newFirst; last = newLast; }; }; Problem solved, you can't access `first` and `last` outside the class. You might retort "they're bigger" or something but just like everything else in JS they just need the right pe…

[deleted]

Re: Classes are Expressions

#19

Post by serve_yay » Thu, Jun 04, 2015, 8:21 PM UTC

greggman wrote: post #13

I guess I need to be schooled by why not just use closures? var Person = function(first last) { this.fullName = function() { return first + " " + last; }; this.rename = function(newFirst, newLast) { first = newFirst; last = newLast; }; }; Problem solved, you can't access `first` and `last` outside the class. You might retort "they're bigger" or something but just like everything else in JS they just need the right pe…

I don't understand why you're talking about this like yours is the normal way and his isn't, or something. Symbols are "real" too.

Re: Classes are Expressions

#20

Post by [deleted] » Thu, Jun 04, 2015, 8:22 PM UTC

greggman wrote: post #13

I guess I need to be schooled by why not just use closures? var Person = function(first last) { this.fullName = function() { return first + " " + last; }; this.rename = function(newFirst, newLast) { first = newFirst; last = newLast; }; }; Problem solved, you can't access `first` and `last` outside the class. You might retort "they're bigger" or something but just like everything else in JS they just need the right pe…

[deleted]