Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Classes are Expressions

raganwald.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Classes are Expressions

#41

Post by stuartaxelowen »

wvenable wrote: post #22
keithwhor wrote: post #16

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…

You can't check that the convention is being broken which makes refactoring more difficult. There will always be a temptation for some developers in some situations to mess with the internal state of objects.

As they say in Python - we're all consenting adults.

Re: Classes are Expressions

#42

Post by woah »

wvenable wrote: post #40
woah wrote: post #36

Earlier quoted context omitted.

In general, js is more about good practices and craftsmanship, and less about finding ways for the language to force people to do things.

I find this argument to be lacking; if you're using good practices and craftsmanship then nothing is being forced on you as you would not encounter an error for doing something improper. I prefer to mark up my code as private/protected/public for my own purposes both as built-in documentation and to have one less thing to think about after it's done. Plus underscores are ugly.

Yes, but you have to do a lot more typing, plus you have to do a lot of things to satisfy a stricter language. There are a lot of abstractions like interfaces, delegates, etc, that exist to get certain logical patterns past the language's strictness. In loose languages you can just write the patterns you want without the overhead.

Re: Classes are Expressions

#43

Post by togakangaroo »

keithwhor wrote: post #16

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…

Fantastic, now what if your domain model actually requires an underscore in things? Or more realistically umm ... ooh ... I dunno, how about I want to write some infrastructure, that iterates over objects? Surely, that's not a thing we use literally all the time. But hey, just write the code to filter out underscores.

Oh wait, now I'm passing my object to a third party library that preforms infrastructure? I guess they better provide a hook that I can inject my own naming conventions.

Yes, underscore fields work, until they don't. Is a function that returns an object really that hard for beginners? I can answer that as I actually teach beginners - yes, it's hard for like two class sessions, after the third homework assignment they have no other issues. So yeah, closures are the way to solve this.

I wouldn't use what this article proposes unless I definitely needed classes, but for the 1% of the time that I do this is a pretty nifty solution to one of my biggest gripes.

Re: Classes are Expressions

#44

Post by wvenable »

woah wrote: post #42
wvenable wrote: post #40

Earlier quoted context omitted.

I find this argument to be lacking; if you're using good practices and craftsmanship then nothing is being forced on you as you would not encounter an error for doing something improper. I prefer to mark up my code as private/protected/public for my own purposes both as built-in documentation and to have one less thing to think about after it's done. Plus underscores are ugly.

Yes, but you have to do a lot more typing, plus you have to do a lot of things to satisfy a stricter language. There are a lot of abstractions like interfaces, delegates, etc, that exist to get certain logical patterns past the language's strictness. In loose languages you can just write the patterns you want without the overhead.

In other words, with less strict languages you can be sloppier. Once projects get to a certain size, language strictness is a huge benefit.

And, in some extent, it's actually freeing. I can reach in and change something big in a strict/compiled language and the compiler/IDE will tell me where I have to make other changes throughout the whole project. In a dynamic language, I either have to rely on unit testing, grep, or just having it break at runtime. But the real truth is, you just don't make those kind of changes when your language isn't strict. The pain isn't worth the payoff.

Re: Classes are Expressions

#45

Post by gcb0 »

munificent wrote: post #25
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…

Closures give you object privacy. Symbols give you class (or whatever other scope you want) privacy. Take a look at this symbol example: let Person = (() = > { let firstNameProperty = Symbol('firstName'), lastNameProperty = Symbol('lastName'); return class Person { constructor (first, last) { this[firstNameProperty] = first; this[lastNameProperty] = last; } sameFirstName (otherPerson) { return this[firstNameProperty]…

so, it is exactly the same as (assume the keys are in a closure i'm too lazy to type it all)

function Person(first, last){ var firstNameProperty = {}, // unique snowflake obj lastNameProperty = {} // yet another unique obj this[firstNameProperty] = first; this[lastNameProperty] = last; }

ES6 should be saving me from typing all the scoping hacks such as closure. not giving me syntax sugar for things i could do already without odd language constructs (now i have to run TWO loops to get my obj properties. which is what everyone is going to do anyway, since you can iterate on all the symbol properties anyway)

Re: Classes are Expressions

#46

Post by gotofritz »

quad50 wrote: post #39
keithwhor wrote: post #16

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…

What are the reasons for keeping components of a 'thing' private? I go back and forth on this. 1. expose a clean API surface so users don't care how it works (as long as it works :) 2. make it easier to change the innards without changing its public behavior 3. keep malicious programmers from delving into the innards of our precious code. It seems like a lot of the discussions on encapsulation (over many years) focus…

It doesn't have to be "malicious" programmers. It can be less experienced, lazy, or under-pressure colleagues.
Post reply on HN