6 ms·

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 wi

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.

wvenable 11y ago
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.
- Jare 11y ago
  Developers willing to make messes in the code must be identified ASAP, and the "_" acts as an easy to see red flag.
- woah 11y ago
  In general, js is more about good practices and craftsmanship, and less about finding ways for the language to force people to do things.
  - wvenable 11y ago
    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.
    - woah 11y ago
      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.
      - wvenable 11y ago
        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.
- stuartaxelowen 11y ago
  As they say in Python - we're all consenting adults.
matchu 11y ago
I like the simple syntax of the underscore convention, and I also appreciate that the article's approach actually enforces the encapsulation. I wonder if there's a convenient way to use this structure and also keep the simpler syntax. Heck, you could probably make a macro such that `this._foo` compiles to `this[privateProperties.foo]`, but I'd probably scream about how misleading that is…
nickbauman 11y ago
Python has been doing this forever and it just works. Objective-C has had access modifiers and such but I find nobody uses them either. It's a baroqueism.
quad50 11y ago
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) focuses on #3. Especially in the C++ and Java world. But worrying about that leads to various forms of obfuscation that make the code worse. And who cares about folks who will hack our objects? That's their problem.
- gotofritz 11y ago
  It doesn't have to be "malicious" programmers. It can be less experienced, lazy, or under-pressure colleagues.
togakangaroo 11y ago
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.

wvenable 11y ago

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.

Jare 11y ago
Developers willing to make messes in the code must be identified ASAP, and the "_" acts as an easy to see red flag.
woah 11y ago
In general, js is more about good practices and craftsmanship, and less about finding ways for the language to force people to do things.
- wvenable 11y ago
  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.
  - woah 11y ago
    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.
    - wvenable 11y ago
      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.
stuartaxelowen 11y ago
As they say in Python - we're all consenting adults.

matchu 11y ago

I like the simple syntax of the underscore convention, and I also appreciate that the article's approach actually enforces the encapsulation. I wonder if there's a convenient way to use this structure and also keep the simpler syntax. Heck, you could probably make a macro such that `this._foo` compiles to `this[privateProperties.foo]`, but I'd probably scream about how misleading that is…

nickbauman 11y ago

Python has been doing this forever and it just works. Objective-C has had access modifiers and such but I find nobody uses them either. It's a baroqueism.

quad50 11y ago

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) focuses on #3. Especially in the C++ and Java world. But worrying about that leads to various forms of obfuscation that make the code worse. And who cares about folks who will hack our objects? That's their problem.

gotofritz 11y ago
It doesn't have to be "malicious" programmers. It can be less experienced, lazy, or under-pressure colleagues.

togakangaroo 11y ago

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.